Входы на ноутбуке для чего они предназначены. Порты и разъемы современных устройств: Документные сканеры. Разъем для подключения док-станции, порта-репликатора

На iOS - iPhone, iPod touch 10.04.2019

На iOS - iPhone, iPod touch

DTD представляет собой совокупность синтаксических правил, на основе которых проверяется структура документа XML. В DTD явно определяется структура документа XML, указываются элементы и их атрибуты, а также приводится другая информация, распространяющаяся на все документы XML, созданные на основе данного DTD.

Учтите, что наличие DTD не является обязательным. Если DTD существует, система XML руководствуется им при интерпретации документа XML. Если DTD отсутствует, предполагается, что система XML должна интерпретировать документ по собственным правилам. Впрочем, для документов XML все же рекомендуется создавать DTD, поскольку это упрощает их интерпретацию и проверку структуры.

DTD можно включить непосредственно в документ XML, сослаться на него по URL или использовать комбинацию этих двух способов. При непосредственном включении DTD в документ XML определение DTD располагается сразу же после пролога:

Атрибут имя_корневого_элемента соответствует имени корневого элемента в тегах, содержащих весь документ XML. В секции «прочих объявлений» находятся определения элементов, атрибутов и т. д.

Возможно, вы предпочитаете разместить DTD в отдельном файле, чтобы обеспечить модульную структуру программы. Давайте посмотрим, как выглядит ссылка на внешний DTD в документе XML. Задача решается одной простой командой:

Как и в случае с внутренним объявлением DTD, имя_корневого_элемента должно соответствовать имени корневого элемента в тегах, содержащих весь документ XML. Атрибут SYSTEM указывает на то, что some_dtd.dtd находится на локальном сервере. Впрочем, на файл some_dtd.dtd также можно сослаться по его абсолютному URL. Наконец, в кавычках указывается URL внешнего DTD, расположенного на локальном или на удаленном сервере.

Как же создать DTD для листинга 14.1? Во-первых, мы собираемся создать в документе XML ссылку на внешний DTD. Как упоминалось в предыдущем разделе, ссылка на DTD выглядит так:

Возвращаясь к листингу 14.1, мы видим, что cookbook является именем корневого элемента, a cookbook.dtd - именем DTD-файла. Содержимое DTD показано в листинге 14.2, а ниже приведены подробные описания всех строк.

Листинг 14.2. DTD для листинга 14.1(cookbook.dtd)

] >

Что же означает этот загадочный документ? Несмотря на внешнюю сложность, в действительности он довольно прост. Давайте переберем все содержимое листинга 14.2:

Перед нами пролог XML, о котором уже говорилось выше.

Третья строка описывает элемент XML, в данном случае - корневой элемент cookbook. После него следует слово recipe, заключенное в круглые скобки. Это означает, что в теги cookbook заключается вложенный тег с именем recipe. Знак + говорит о том, что в родительских тегах cookbook находится одна или несколько пар тегов recipe.

Четвертая строка описывает тег recipe. В ней сообщается, что в тег recipe входят четыре вложенных тега: title, description, ingredients и process. Поскольку после имен тегов не указываются признаки повторения(см. следующий раздел), внутри тегов recipe должна быть заключена ровно одна пара каждого из перечисленных тегов.

Перед нами первое определение тега, который не содержит вложенных тегов. В соответствии с определением он содержит #PCDATA, то есть произвольные символьные данные, не считающиеся частью разметки.

В соответствии с определением элемент ingredients содержит один или несколько тегов с именем ingredient. Обратитесь к листингу 14.1, и вы все поймете.

Поскольку элемент ingredient соответствует отдельному ингредиенту, вполне логично, что этот элемент содержит простые символьные данные.

Элемент process содержит один или несколько экземпляров элемента step.

Элемент step, как и элемент ingredient, соответствует отдельному пункту в списке более высокого уровня. Следовательно, он должен содержать символьные данные.

Обратите внимание: элемент recipe в листинге 14.1 содержит атрибут. Этот атрибут, category, определяет общую категорию, к которой относится рецепт - в приведенном примере это категория «итальянская кухня»(Italian). В определении ATTLIST указывается как имя элемента, так и имя атрибута. Кроме того, отнесение каждого рецепта к определенной категории упрощает классификацию, поэтому атрибут объявляется обязательным(#REQUIRED).

Последняя строка просто завершает определение DTD. Определение всегда должно быть должным образом завершено, иначе произойдет ошибка.

В завершение этого раздела я приведу сводку основных компонентов типичного DTD-файла:

объявления типов элементов;
объявления атрибутов;
ID, IDREF и IDREFS;
объявления сущностей.

Некоторые из этих компонентов уже встречались нам в описании листинга 14.2. Далее каждый компонент будет описан более подробно.

Объявления элементов

Все элементы, используемые в документе XML, должны быть определены в DTD, прилагаемом к документу. Мы уже встречались с двумя распространенными разновидностями определений: для элемента, содержащего другие элементы, и элемента, содержащего символьные данные. Данное определение свидетельствует, что элемент содержит только символьные данные:

Следующее определение элемента process говорит о том, что он содержит ровно один вложенный элемент с именем step:

Впрочем, процессы(process) из одного шага(step) встречаются довольно редко - скорее всего, шагов будет несколько. Чтобы указать, что элемент содержит один или несколько экземпляров вложенного элемента step, следует воспользоваться признаком повторения:

Количество вложенных элементов можно задать несколькими способами. Полный список операторов элементов приведен в табл. 14.1.

Таблица 14.1. Операторы элементов

Если элемент будет содержать несколько вложенных элементов, их следует перечислить через запятую в определении родительского элемента:

Поскольку признаки повторения не указаны, каждый тег должен встречаться ровно один раз.

Определение элемента уточняется при помощи логических операторов. Предположим, вы работаете с рецептами, в которые всегда входят макароны(pasta) с одним или несколькими типами сыра(cheese) или мяса(meat). В этом случае элемент ingredient определяется следующим образом:

Поскольку элемент pasta обязательно должен присутствовать в элементе ingredient, он указывается с признаком повторения +. Затем следует либо элемент cheese, либо элемент meat; мы разделяем альтернативы вертикальной чертой и заключаем их в круглые скобки со знаком +, поскольку в рецепт всегда входит либо одно, либо другое.

Существуют и другие разновидности определений элементов. Мы рассмотрели лишь простейшие случаи. Тем не менее, приведенного материала вполне достаточно для понимания примеров, приведенных в оставшейся части этой главы.

Объявления атрибутов

Атрибуты элементов описывают значения, связываемые с элементами. Элементы XML, как и элементы HTML, могут иметь ноль, один или несколько атрибутов. Общий синтаксис объявления атрибутов выглядит следующим образом:

Имя_элемента определяет имя элемента, включаемое в тег. Затем перечисляются атрибуты, связанные с данным элементом. Объявление каждого атрибута состоит из трех основных компонентов: имени, типа данных и флага, определяющего особенности данного атрибута. Вместо многоточия(...) могут быть расположены объявления других атрибутов.

Простое объявление атрибута уже встречалось нам в листинге 14.2:

Тем не менее, как видно из приведенного общего определения, допускается одновременное объявление нескольких атрибутов. Допустим, в дополнение к атрибуту category вы хотите связать с элементом recipe дополнительный атрибут difficulty(сложность приготовления). Оба атрибута объявляются в одном списке:

Форматировать объявления подобным образом необязательно; тем не менее, многострочные объявления нагляднее однострочных. Кроме того, поскольку оба атрибута являются обязательными, тег reci ре не может ограничиться каким-нибудь одним атрибутом, он должен включать в себя оба атрибута сразу. Например, следующий тег будет считаться неверным:

Почему? Потому что в нем отсутствует атрибут category. Правильный тег должен содержать оба атрибута:

Особые условия обработки атрибута описываются тремя флагами, перечисленными в табл. 14.2.

Таблица 14.2. Флаги атрибутов

Типы атрибутов

Атрибут элемента может объявляться с определенным типом. Типы атрибутов описаны далее.

Атрибуты CDATA

Очень часто атрибуты содержат общие символьные данные. Такие атрибуты называются атрибутами CDATA. Следующий пример уже встречался в начале этого раздела:

Атрибуты ID, IDREF и IDREFS

Идея однозначного представления данных(например, информации о пользователе или товаре, хранящейся в базе данных) посредством идентификаторов неоднократно встречалась в предыдущих главах книги. Идентификаторы также часто используются в XML, поскольку перекрестные ссылки между документами применяются не только в общих задачах обработки данных, но и в World Wide Web(гиперссылки).

Идентификаторы элементов присваиваются атрибуту ID. Допустим, вы хотите связать с каждым рецептом уникальный идентификатор. Соответствующий фрагмент DTD может выглядеть так:

После этого объявление элемента recipe в документе может выглядеть так:
Spaghetti alla Carbonara
Рецепт однозначно определяется идентификатором ital003. Следует помнить, что атрибут redpe-id относится к типу ID, поэтому ital003 не может использоваться в качестве значения атрибута recipe-id другого элемента, в противном случае документ будет считаться синтаксически неверным. Теперь допустим, что позднее вы захотели сослаться на этот рецепт из другого документа - скажем, из списка любимых рецептов пользователя. Именно здесь в игру вступают перекрестные ссылки и атрибут IDREF. Атрибуту IDREF присваивается идентификатор, используемый для ссылок на элемент, - по аналогии с тем, как URL используется для идентификации страницы в гиперссылке. Рассмотрим следующий фрагмент кода XML:

В процессе обработки документа XML элемент заменяется более наглядной ссылкой на рецепт с указанным идентификатором(например, названием рецепта). Вероятно, он будет отформатирован в виде гиперссылки, чтобы упростить переход к указанному рецепту.

Перечисляемые атрибуты

При объявлении атрибута можно перечислить все допустимые значения, принимаемые атрибутом. В нашем примере это было бы удобно, поскольку вы можете сразу определить список допустимых категорий. Приведенное выше объявление записывается в следующем виде:

Обратите внимание: при использовании списков допустимых значений включать в объявление тип CDATA не нужно, поскольку все перечисленные значения относятся к формату CDATA.

Перечисляемые атрибуты со значением по умолчанию

Иногда бывает удобно объявить для атрибута значение по умолчанию. Скорее всего, вам уже приходилось делать это раньше при построении форм с раскрывающимися списками. Например, если большинство рецептов в вашей поваренной книге относится к итальянской кухне, атрибут recipe будет часто относиться к категории Italian. В этом случае категорию Italian можно назначить по умолчанию:

Если атрибут category не задан явно, по умолчанию ему присваивается значение Italian.

Атрибуты ENTITY и ENTITIES

Данные в документах XML не всегда являются текстовыми - документ может содержать и двоичную информацию(например, графику). На такие данные можно ссылаться при помощи атрибута entity. Например, в описании элемента description можно указать атрибут recipePicture с графическим изображением:

Также можно объявить сразу несколько сущностей, заменив ENTITY на ENTITIES. Значения разделяются пробелами.

Атрибуты NMTOKEN и NMTOKENS

Атрибуты NMTOKEN представляют собой строки из символов, входящих в ограниченный набор. Объявление атрибута с типом NMTOKEN предполагает, что значение атрибута соответствует установленным ограничениям. Как правило, значение атрибута NMTOKEN состоит из одного слова:

Можно объявить сразу несколько атрибутов, заменив NMTOKEN на NMTOKENS. Значения разделяются пробелами.

Объявления сущностей

Объявление сущности напоминает команду define в некоторых языках программирования, включая РНР. Ссылки на сущности кратко упоминались в предыдущем разделе «Знакомство с синтаксисом XML». На всякий случай напомню, что ссылка на сущность используется в качестве замены для другого фрагмента содержания. В процессе обработки документа XML все вхождения сущности заменяются содержанием, которое она представляет. Существует два вида сущностей: внутренние и внешние.

Внутренние сущности

Внутренние сущности напоминают строковые переменные, связывающие имя с фрагментом текста. Например, если вы хотите определить имя для ссылки на информацию об авторских правах, можно объявить сущность следующего вида:

В процессе обработки документа все экземпляры &Соруright заменяются текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

Внутренние сущности удобны в ситуациях, когда вы планируете использовать сущность в относительно небольшом количестве документов XML. При большом количестве документов лучше воспользоваться внешними сущностями.

Внешние сущности

Внешние сущности используются для ссылок на содержание, находящееся в другом файле. Сущности этого типа могут содержать текстовую информацию, но также могут ссылаться и на двоичные данные(например, графику). Возвращаясь к предыдущему примеру, допустим, что вы решили сохранить информацию об авторских правах в отдельном файле, чтобы упростить ее редактирование в будущем. Ссылка на созданный файл выглядит следующим образом:

При последующей обработке документа XML все ссылки &Соруright заменяются содержимым документа copyright.xml. Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

Внешние сущности также удобно использовать для ссылок на графические изображения. Например, если вы хотите включить в документ XML графический логотип, создайте внешнюю сущность:

Ресурсы, посвященные XML

Хотя приведенного выше материала вполне достаточно для понимания базовой структуры документов XML, данное описание не является полным. Ниже приведены ссылки на ресурсы Интернета, содержащие более подробную информацию:

В оставшейся части главы рассказано о том, как использовать РНР для обработки документов XML. На первый взгляд задача кажется очень сложной(лексический анализ любых документов любого типа вызывает немало затруднений).

Но стоит познакомиться с базовой стратегией работы с XML в РНР, и все оказывается на удивление просто.

Аннотация: В данном разделе описываются общие принципы написания Определение типа документа. Так же рассмотрены основные недостатки и особенности DTD.
Зачем нужно DTD.
Создавая XML документ разработчик сам решает: как назвать теги, в каком порядке они будут следовать, какие данные будут записаны в том или ином элементе, будут ли у элемента атрибуты или нет и многое другое. Без формального описания структуры документа этим самым документом может воспользоваться только его разработчик. В случае если разработанный XML документ предназначен для передачи во внешний мир, например партнерам по бизнесу, и если к тому же планируется получать в ответ документы, написанные в том же самом формате без определения типов документов ( Document Type Definition , DTD ) не обойтись. Это связано с тем, что для того, что бы обе стороны могли понимать полученную информацию элементы и атрибуты в документах должны употребляться всеми сторонами одинаково. Определения типа документа вносят строгость и точность в правила написания правильно оформленных документов XML . Хранимые в начале файла XML или внешним образом в виде файла *.DTD , определения типов документов описывают информационную структуру документа. В DTD перечисляются возможные имена элементов, определяются имеющиеся атрибуты для каждого типа элементов и описывается вложенность элементов.
XML используется в качестве средства для описания грамматики других языков. И таким образом разрабатывая некоторый язык для написания XML документов в той или иной области нам придется разработать словарь данной области деятельности. DTD по определению содержат всю информацию которая может появиться в XML документе. Все, что входит в проект, должно быть включено в DTD . Таким образом DTD описания в сущности и является таким словарем. Современный мир меняется достаточно динамично поэтому заранее не известно какая информация может потребоваться в дальнейшем и для того что бы не пришлось часто изменять структуру документов обычно разрабатываемый словарь включает в себя все что может понадобиться для конкретных видов бизнеса или промышленности. Это позволяет использовать определения DTD как средство анализа и проектирования. Приложения XML взаимодействуют друг с другом на основе словарей, которые они понимают, так что определение DTD помогает понять, что может описать приложение .
Другое применение DTD это проверка написанного XML документа на корректность . Правильно оформленные документы, написанные в соответствии со всеми правилами, описанными в спецификации XML , не могут быть проверены на предмет ошибок. Пропущенные ошибки могут вызвать повреждение программы обрабатывающей данные документы, либо ввод в систему неверных данных. Но если документ ссылается на определение DTD , то, используя проверяющий на допустимость анализатор можно проверить, есть ли в нашем документе ошибки. Анализатор затребует DTD и убедится, что документ соответствует описанным в нем грамматическим правилам. Анализатор обнаруживает структурные ошибки и ошибки содержания, что намного уменьшает объем проверок, выполняемых логикой приложения.

Написание определений DTD: общие принципы.

Ассоциирование DTD с документом XML
Для связывания декларации DTD с экземпляром документа в версии XML 1.0 предлагается специальная декларация DOCTYPE . Она должна следовать после декларации XML и предшествовать любым элементам документа. Тем не менее, между декларациями XML и DOCTYPE могут находиться комментарии и команды обработки.
Декларация DOCTYPE содержит ключевое слово DOCTYPE , за которым следует имя корневого элемента документа, а затем конструкция с декларациями содержания. Перед разъяснением этого утверждения рассмотрим пример расположения декларации DOCTYPE в экземпляре документа. Ниже приводятся первые три строчки документа XML:
.. …
Можно написать внешнее подмножество деклараций в отдельном файле DTD , включить внутреннее подмножество в тело декларации DOCTYPE или сделать то и другое. В последнем случае (смешение внутренних и внешних DTD ) во внутренних DTD могут быть заданы новые декларации или переписаны те, что содержатся во внешних (по определению спецификации XML анализаторы сначала читают внутреннее подмножество, и потому содержащиеся там декларации пользуются приоритетом).
Декларации XML могут содержать атрибут standalone, принимающий только значения "yes" и "nо". Если значение атрибута равно yes, то внешние для экземпляра документа декларации не влияют на информацию, передаваемую документом использующему его приложению. Значение no показывает, что существуют внешние декларации со значениями, необходимыми для правильного описания содержания документа - например конкретные значения по умолчанию. На практике необязательный атрибут standalone используется редко. Наличие этого атрибута со значением, yes не гарантирует отсутствия внешних зависимостей любого типа. Просто внешние зависимости в этом случае не приведут к ошибке в документе, если не будут включены в обработку. Таким образом, в основном этот атрибут представляет собой знак для анализаторов и других приложений, показывающий, нужно ли им использовать какое-либо внешнее содержание.
Блок внутренней декларации разметки тега DOCTYPE состоит из левой квадратной скобки, списка деклараций и правой квадратной скобки:
Внутренние DTD очень полезны, они всегда содержатся в использующем их документе и поэтому их получение анализатором не представляет проблем. Однако внутренние DTD значительно увеличивают размер документа. На практике внутренние DTD чаще всего применяются одновременно с внешними для добавления новых декларации. Если там объявлен какой-либо объект, продекларированный также и во внешнем определении DTD , приоритетом пользуется внутреннее. Это позволяет осуществлять тонкую настройку деклараций для нужд конкретных документов.
Внешние DTD в некоторых отношениях более гибкие. В данном случае декларация DOCTYPE состоит из обычного ключевого слова и имени корневого элемента, за которым следует еще одно ключевое слово SYSTEM либо PUBLIC , обозначающее источник внешнего определения DTD , а за ним - локализация этого определения. Если ключевое слово SYSTEM , DTD обязано непосредственно и явным образом находится по указанному URL адресу.
Если внешние DTD переписываются очень часто, они начинают терять свое значение, а это признак плохого первоначального проекта.
Ключевое слова PUBLIC предназначено для хорошо известных словарей. Приложение, анализирующее документ из этого словаря, должно использовать некоторую стратегию по поиску соответствующего DTD .
Стандарт XML 1.0 допускает у декларации PUBLIC наличие как публичного URI , так и системного идентификатора. Если работающее с документом приложение или анализатор не могут найти DTD по идентификатору URI с ключевым словом PUBLIC , оно должно использовать системный идентификатор.

Основные декларации разметки
Допустимое в документе XML содержание определяется с помощью четырех типов декларации разметки в DTD . В следующей далее таблице показаны связанные с этими декларациями ключевые слова и их значения:
Первые два типа связаны с информацией, которую мы рассчитываем найти в документе XML, - элементами и атрибутами.
Последние два типа используются для поддержки. Особенно облегчают жизнь разработчика словаря XML сущности. Как правило, они состоят из содержания, которое настолько часто используется в DTD или документе, что оправдывает создание специальной декларации. Применение этой декларации напоминает оператор include в языках C/C++ , когда в качестве замены для содержания используется имя.
Нотации описывают содержание, разработанное не на языке XML. Используются они для того, чтобы объявить конкретный класс данных и связать его с внешней программой. Эта внешняя программа становится обработчиком объявленного класса данных. Например, связав с документом изображение в формате JPEG, разработчик желает, чтобы программа приняла и визуализировала двоичные данные в этом формате. Конечно, в таком случае документ зависит от того, какой обработчик имеется в системе, получающей документ. В интересах портативности и переносимости некоторые авторы не приводят ссылки на обработчики. В таком случае нотация превращается просто в механизм набора текста.

Используйте для определения структуры XML-документов XML-схемы вместо DTD

XML-схема обладает более мощными возможностями, чем DTD. Для иллюстрации преимуществ использования механизма XML-схем в первых трех листингах сравниваются различные способы представления элементов. В представлена выдержка из XML-документа. В показаны два элемента, объявленные в синтаксисе DTD, а в представлен синтаксис, соответствующий XML-схеме. Обратите внимание, что синтаксис в Листинге 3 подобен синтаксису XML. При использовании схемы, валидирующий парсер может выполнить проверку, является ли элемент InvoiceNo положительным целым числом, и состоит ли ProductID из заданного набора символов (шести цифр и одной буквы от A до Z). Парсер, обрабатывающий DTD-определение, может лишь подтвердить, что данные элементы представляют собой строки.
Листинг 1: Фрагмент XML-документа
123456789 J123456
Листинг 2: Фрагмент DTD, описывающий элементы из Листинга 1

Листинг 3: Фрагмент XML-схемы, описывающий элементы из Листинга 1

Использование пространств имен в XML-схеме
Ограничения DTD
Несмотря на то, что DTD служат разработчикам SGML и HTML в качестве механизма описания структурированной информации вот уже на протяжении 20-ти лет, DTD обладают некоторыми ограничениями по сравнению с XML-схемами.
Согласно DTD элемент может быть представлен одним из трех способов:
Текстовая строка
Текстовая строка, смешанная с другим дочерним элементом
Набор дочерних элементов

DTD не обладает синтаксисом XML и предлагает лишь ограниченную поддержку для типов и пространств имен.
При совместной работе одна сторона может обрабатывать документы других сторон, и разные стороны могут представлять свои элементы данных по-разному. Более того, в отдельном документе им может потребоваться независимо друг от друга ссылаться на элементы с одинаковым именем, созданные разными сторонами. Использование XML-схемы позволяет различать определения с одним и тем же именем при помощи определения разных пространств имен.
Такая XML-схема определяет набор новых имен, таких как имена элементов, типов, атрибутов, групп атрибутов, чьи определения и объявления описаны в схеме. В имена определяются как InvoiceNo , ProductID и ProductCode .
Имена, определенные в схеме принадлежат так называемому целевому пространству имен . Само по себе пространство имен является фиксированным, произвольным именем, которое должно соответствовать синтаксису URL. К примеру, пространство имен для схемы, представленной в , можно задать следующим образом: http://www.SampleStore.com/Account .
Синтаксис объявления пространства имен иногда может сбить с толку. Объявление начинается с http:// , однако оно не ссылается на файл с описанием схемы. На самом деле, ссылка http://www.SampleStore.com/Account вообще не ведет ни на один файл, а только на назначенное имя.
Определения и объявления в схеме могут ссылаться на имена, которые могут принадлежать другим пространствам имен. В данной статье мы ссылаемся на такие пространства имен как на исходные пространства имен . В каждой схеме может быть определено одно целевое пространство имен и возможно множество исходных пространств имен. Вообще, каждое имя в заданной схеме принадлежит некоему пространству имен. Имена пространства имен могут быть довольно длинными, однако их можно сократить при помощи синтаксиса объявления xmlns в документе XML-схемы. Все эти концепции проиллюстрированы в .
Листинг 4: Целевое и исходное пространства имен

В XML-схеме, представленной с , пространством имен targetNamespace является http://www.SampleStore.com/Account , оно содержит имена InvoiceNo , ProductID и ProductCode . Имена schema , element , simpleType , pattern , string и positive-integer принадлежат исходному пространству имен http://www.w3.org/1999/XMLSchema , которое сокращается как xsd путем объявления xmlns . В псевдониме xsd нет ничего особенного, можно выбрать и другое имя. Для удобства и простоты в оставшейся части статьи мы будем использовать префикс xsd для ссылки на пространство имен http://www.w3.org/1999/XMLSchema , пропуская уточнение xsd в некоторых частях кода. В нашем примере targetNamespace является также одним из исходных пространств имен, так как имя ProductCode используется в определении других имен.
Рисунок 1: Пространства имен для Листинга 4
Листинг 5: Множество исходных пространств имен, импорт пространства имен

Определение элементов
Определением элемента заключается в определении его имени и модели контента. В XML-схеме модель контента элемента определяется его типом. Следовательно, элементы в XML-документе могут иметь только значения, которые подходят типам, определенным в его схеме.
Простые типы
Спецификация XML-схемы определяет несколько простых типов для значений, как показано в Таблице 2 -предопределенные простые типы значений.
Тип элемента может быть простым или комплексным (сложным). Элемент простого типа не может содержать другие элементы или атрибуты. Комплексный тип может создавать эффект встраивания элементов в другие элементы или может ассоциировать атрибуты с элементом. До этого момента мы использовали только примеры с простыми типами, определенными пользователем (см. ProductCode). В спецификацию XML-схемы также включены предопределенные простые типы (см. вставку ). Предопределенный простой тип ограничивает значения по их базовому типу. К примеру, значением предопределенного простого типа ProductCode является подмножество значений базового типа string .
Простые, не вложенные элементы имеют простой тип
Элемент, который не содержит атрибутов или других элементов может быть отнесен к простому типу, предопределенному или определенному пользователем, такому как string , integer , decimal , time , ProductCode и т.п.
Листинг 7: Некоторые простые типы элементов

Элементы с атрибутами должны иметь комплексный тип
Теперь попробуем добавить к простому элементу price из атрибут currency . Вы не сможете этого сделать, так как элемент простого типа не может иметь атрибутов. Если вы хотите добавить атрибут, вам необходимо определить price как элемент комплексного типа. В примере из , мы определяем, так называемый анонимный тип , в котором комплексному типу не дается явного имени. Другими словами, атрибут name элемента complexType не определен.
Листинг 8: Элемент комплексного типа

Элементы, содержащие вложенные элементы должны иметь комплексный тип
В XML-документе в элемент могут быть вложены другие элементы. Это требование выражается напрямую в DTD. XML-схема вместо этого определяет элемент и его тип, который может включать объявления других элементов и атрибутов. Пример приведен в .
Таблица 1: Сравнение комплексных типов данных в DTD и XML-схеме
XML-документ
Cool XML<Title> <Author>Cool Guy</Author> </Book> <h5>DTD</h5> <!ELEMENT Book (Title, Author)> <!ELEMENT Title (#PCDATA)> <!ELEMENT Author (#PCDATA)> <h5>XML-схема</h5> <element name="Book" type="BookType"/> <complexType name="BookType"> <element name="Title" type="string"/> <element name="Author" type="string"/> </complexType> <h5>Листинг 10: Скрытие BookType как локального типа</h5> <element name="Title" type="string"/> <element name="Author" type="string"/> <element name="Book"> <complexType> <element ref="Title"/> <element ref="Author"/> </complexType> </element> <h2>Выражение сложных ограничений для элементов</h2>XML-схема предлагает большую гибкость, чем DTD при выражении ограничений для модели контента элементов. На простейшем уровне, таком как в DTD, вы можете ассоциировать с элементом атрибуты, а также указать, что в нем может появляться последовательность из только одного (1), нуля или более (*), или одного или более (+) элементов из заданного набора элементов. В XML-схеме можно выразить дополнительные ограничения, используя для этой цели, к примеру, атрибуты minOccurs и maxOccurs для элемента element и элементы choice , group и all .<h5>Листинг 11: Выражение ограничений для типов элементов</h5> <element name="Title" type="string"/> <element name="Author" type="string"/> <element name="Book"> <complexType> <element ref="Title"/> <element ref="Author"/> </complexType> </element> В тег Title является опциональным по отношению к тегу Book (такое же правило можно задать и в DTD). Однако здесь также говорится, что в элементе Book должен быть хотя бы один и не более двух элементов Author . Значением атрибутов minOccurs и maxOccurs тега element по умолчанию является 1. Элемент choice указывает на то, что может появиться только один из указанных дочерних элементов. Другой элемент all определяет, что все дочерние элементы могут появляться только один раз, вместе и в любом порядке, или не появляться совсем. В объявляется, что оба <a href="/kakoi-element-yavlyaetsya-roditelskim-dlya-tega-title-znachenie/">тега Title</a> и Author должны появляться в Book в любом порядке, или не появляться вообще. Подобные ограничения сложно выразить при помощи DTD.<h5>Листинг 12: Указатель того, что у элемента должны быть определены все типы</h5> <xsd:element name="Title" type="string"/> <xsd:element name="Author" type="string"/> <xsd:element name="Book"> <xsd:complexType> <xsd:all> <xsd:element ref="Tile"/> <xsd:element ref="Author"/> </xsd:all> </xsd:complexType> </xsd:element> <h2>Подведение итогов</h2>В данном документе мы раскрыли при помощи простых примеров наиболее фундаментальные концепции, необходимые для определения структуры элементов при помощи XML-схемы. Доступно также множество других мощных механизмов:<ul><li>XML-схема содержит всестороннюю поддержку для наследования типов, позволяя повторно использовать определенные ранее структуры. Такое использование называют аспектами . Вы можете вывести новые типы, представляющие меньшее подмножество значений других типов, к примеру, для определения подмножества по перечислению, диапазону или по совпадению с шаблоном. В одном из примеров данной статьи тип ProductCode был определен с использованием аспекта pattern . В подтипе также можно добавить для базового типа новые элементы и атрибуты.</li><li>Несколько механизмов, позволяющих контролировать <a href="/programma-dlya-opredeleniya-obshchego-vremya-raboty-noutbuka-kak-uznat-kogda/">общее определение</a> подтипа или заменять его в определенном документе. К примеру, можно указать, что тип InvoiceType (тип номера инвойса) не может содержать подтипы, то есть никто не сможет определить новую версию InvoiceType . Можно также задать, что в отдельном контексте для типа ProductCode не может быть замещения подтипов.</li><li>Кроме использования подтипов, можно определять эквивалентные типы, то есть значение одного типа может быть замещено значением другого.</li><li>XML-схема обеспечивает механизм для замещения элемента или типа путем объявления их как абстрактных.</li><li>Для большего удобства можно обозначить и задать имена группам атрибутов или элементов. Это позволяет повторно использовать их при последующих обращениях.</li><li>XML-схема предоставляет три элемента – appInfo , documentation и annotation – для использования комментариев, как людьми (documentation) так и приложениями (appInfo)</li><li>Вы можете выразить уникальные ограничения, основывающиеся на определенных атрибутах дочерних элементов.</li> </ul>Дополнительную информацию по XML-схемам можно получить из документаций на сайтах W3C (См. ) и dW XML zone. Теперь, когда спецификация XML-схемы получила подтверждение в качестве кандидата на рекомендацию W3C, вы без сомнения можете использовать ее в полной мере. <h3></h3> В XML - документах DTD определяет набор действительных элементов, идентифицирует элементы, которые могут находиться в других элементах, и определяет действительные атрибуты для каждого из них. Синтаксис DTD весьма своеобразен и от автора-разработчика требуются дополнительные усилия при создании таких документов(сложность DTD является одной из причин того, что использование SGML , требующего определение DTD для любого документа, не получило столь широкого <a href="/sposoby-rasprostraneniya-failov-sposoby-kak-mozhno-zarabotat-na-failoobmennikah/">распространения как</a>, например, HTML ). Как уже отмечалось, в XML использовать DTD не обязательно - документы, созданные без этих правил, будут правильно обрабатываться программой-анализатором, если они удовлетворяют основным требованиям синтаксиса XML . Однако контроль за типами элементов и корректностью отношений между ними в этом случае будет полностью возлагаться на автора документа. До тех пор, пока грамматика нашего нового языка не описана, его сможем использовать только мы, и для этого мы будем вынуждены применять специально разработанное программное обеспечение, а не универсальные программы-анализаторы.. В DTD для XML используются следующие типы правил: правила для элементов и их атрибутов, описания категорий(макроопределений), описание форматов бинарных данных. Все они описывают основные конструкции языка - элементы, атрибуты, символьные константы внешние файлы бинарных данных. Для того, чтобы использовать DTD в нашем документе, мы можем или описать его во внешнем файле и при описании DTD просто указать ссылку на этот файл или же непосредственно внутри самого документа выделить область, в которой определить нужные правила. В первом случае в документе указывается имя файла, содержащего DTD - описания: <?xml version="1.0" standalone="yes" ?> <! DOCTYPE journal SYSTEM "journal.dtd"> ... Внутри же документа DTD- декларации включаются следующим образом: ... <! DOCTYPE journal [ <!ELEMENT journal (contacts, issues, authors)> ... ]> ... В том случае, если используются одновременно внутренние и <a href="/kartrider-dlya-kart-pamyati-chto-delat-esli-on-ne-rabotaet/">внешние описания</a>, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML - процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes" , то использование внешних DTD описаний будет запрещено. <h4>Определение элемента </h4> Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого. Например, для элемента <flower> можно определить следующее правило: <!ELEMENT flower PCDATA> Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML . Внутри этой инструкции задается название элемента (flower) и тип его содержимого. В определении элемента мы указываем сначала название элемента(flower) , а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY ,ANY . Первая указывает на то, что элемент должен быть пустым(например, <red/> ), вторая - на то, что содержимое элемента специально не описывается. Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? : <!ELEMENT issue (title, author+, table-of-contents?)> В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title , author и table-of-contents , причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" : <!ELEMENT flower (PCDATA | title)*> Символ * в этом примере указывает на то, что определяемая последовательность <a href="/sozdanie-ramki-s-pomoshchyu-html-css-border-granicy-elementa-vneshnii-i/">внутренних элементов</a> может быть повторена несколько раз или же совсем не использоваться. Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA , а затем разделенный символом "|" список элементов. Пример корректного XML - документа: <?xml version="1.0"?> <! DOCTYPE journal [ <!ELEMENT contacts (address, tel+, email?)> <!ELEMENT address (street, appt)> <!ELEMENT street PCDATA> <!ELEMENT appt (PCDATA | EMPTY)*> <!ELEMENT tel PCDATA> <!ELEMENT email PCDATA> ]> ... <contacts> <address> <street>Marks avenue</street> <appt id="4"> </address> <tel>12-12-12</tel> <tel>46-23-62</tel> <email>info@j.com</email> </contacts> <h4>Определение атрибутов </h4> Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <article> могут быть определены следующие атрибуты: <!ATTLIST article id ID #REQUIRED about CDATA #IMPLIED type (actual | review | teach) "actual" "" > В данном примере для элемента article определяются три атрибута: id, about и type ,которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть <a href="/tipy-sensornyh-ekranov-vozmozhnye-varianty-raboty-draivera-i-upravleniya/">возможных типов</a> значений атрибута: <ul><li>CDATA - содержимым документа могут быть любые символьные данные </li> <li>ID - определяет уникальный идентификатор элемента в документе </li> <li>IDREF (IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента </li> <li>ENTITY (ENTITIES ) - значение атрибута должно быть названием(или списком названий, если используется ENTITIES ) компонента (макроопределения), определенного в документе </li> <li>NMTOKEN (NMTOKENS ) - содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA ) </li> <li>Список допустимых значений - определяется список значений, которые может иметь данный атрибут. </li> </ul>Также в определении атрибута можно использовать <a href="/kakoi-router-vybrat-dlya-interneta-kakie-parametry-ne-sleduet/">следующие параметры</a>: <ul><li>#REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа </li> <li>#IMPLIED - атрибут не является обязательным </li> <li>#FIXED "значение" - указывает, что атрибут должен иметь только <a href="/znachenie-otpravit-kopiyu-na-ukazannyi-e-mail-elektronnaya-perepiska-kak/">указанное значение</a>, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору </li> <li>Значение - задает значение атрибута по умолчанию </li> </ul><h4>Определение компонентов(макроопределений) </h4> Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD - компоненты при помощи инструкции !ENTITY : <!ENTITY hello " Мы рады приветствовать Вас!" > Программа-анализатор, просматривая в первую очередь содержимое области DTD - определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD - компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello ; , которое будет заменено на строчку " Мы рады приветствовать Вас" В общем случае, внутри DTD можно задать три типа макроопределений: Внутренние макроопределения - предназначены для определения строковой константы, с их помощью можно организовывать ссылки на часто изменяемую информацию, делая документ более читабельным. Внутренние компоненты включаются в документ при помощи амперсанта & В XML существует пять предустановленных внутренних символьных констант: <ul><li>< - символ "<" </li> <li>> - символ ">" </li> <li>& - символ "&" </li> <li>" - символ апострофа """ </li> <li>" - символ двойной кавычки """ </li> </ul>Внешние макроопределения - указывают на содержимое <a href="/net-yavlyaetsya-vnutrennei-ili-vneshnei-komandoi-imya-faila-ne-yavlyaetsya/">внешнего файла</a>, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования макроса будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются и используются внешними программами <!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A> Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом % , вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD - правила Например, для следующего фрагмента документа: <!ELEMENT name (PCDATA)> <!ELEMENT title (PCDATA | name)*> <!ELEMENT author (PCDATA | name)*> <!ELEMENT article (title, author)*> <!ELEMENT book (title, author)*> <!ELEMENT bookstore (book | article)*> <!ELEMENT bookshelf (book | article)*> можно использовать более короткую форму записи: <!ELEMENT name (PCDATA)> <! ENTITY %names "PCDATA | name"> <!ELEMENT article (%names;)*> <!ELEMENT book (%names;)*> <!ENTITY %content "book | article"> <!ELEMENT bookstore (%content;)*> <!ELEMENT bookshelf (%content;)*> Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать <a href="/opredelenie-odinakovyh-failov-na-kompyutere-poisk-i-udalenie-dublikatov/">одинаковые определения</a> атрибутов для различных элементов: <!ENTITY %itemattr "id ID #IMPLIED src CDATA"> <!ENTITY %bookattr "ISDN ID #IMPLIED type CDATA"> <!ENTITY %artattr " size CDATA"> <!ELEMENT book (title, author,content)*> <!ATTLIST book %itemattr %bookattr;> <!ELEMENT article (title, author, content)*> <!ATTLIST article %itemattr %artattr;> <h4>Типизация данных </h4> Довольно часто при создании XML - элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент <last-modified>10.10.98</last-modified> , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL - запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL -запрос. Если в качестве программы на стороне клиента используется верифицирующий XML -процессор, то информацию о типе можно передавать при помощи специально созданного для этого <a href="/atributy-input-html-gruppirovka-elementov-formy-atributy-tega/">атрибута элемента</a>, имеющего соответствующее DTD - определение. В процессе разбора программа-анализатор передаст значение этого атрибута клиентскому приложению, которое сможет использовать эту информацию должным образом. Например, чтобы указать, что содержимое элемента должно быть длинным целым, можно использовать следующее DTD - определение: <!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG"> Задав атрибуту значение по умолчанию LONG и определив его как FIXED , мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD - определении. Вот пример XML - документа, в котором определяются и используются несколько элементов с различными типами данных: <!ELEMENT price (PCDATA)> <!ATTLIST price data_currency CDATA #FIXED "CURRENCY"> <!ELEMENT rooms_num (PCDATA)> <!ATTLIST rooms_num data_byte CDATA #FIXED "BYTE"> <!ELEMENT floor (PCDATA)> <!ATTLIST floor data_byte CDATA #FIXED "INTEGER"> <!ELEMENT living_space (PCDATA)> <!ATTLIST living_space data_float CDATA #FIXED "FLOAT"> <!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG"> <!ELEMENT is_tel (PCDATA)> <!ATTLIST is_tel data_bool CDATA #FIXED "BOOL"> <!ELEMENT house (rooms_num, floor,living_space, is_tel, counter, price)> <!ATTLIST house id ID #REQUIED> ... <house id="0"> <rooms_num>5</rooms_num> <floor>2</floor> <living_space>32.5</living_space> <is_tel>true</is_tel> <counter>18346</counter> <price>34 р. 28 к.</price> </house> ... Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD . В заключении хотелось бы отметить, что DTD предоставляет нам весьма удобный механизм осуществления контроля за содержимым документа. На сегодняшний день, практически все программы просмотра документов Интернет используют DTD -правила. Однако это далеко не единственный способ проверки корректности документа. В настоящий момент в W3 консорциуме находится на рассмотрении новый стандарт языка описания структуры документов, называемый схемами данных. Следующий раздел посвящен работе с ними. </td> Шпаргалка по DTD . DTD – Один из способов формализованного описания схемы документа XML , сделанного на языке, понятном программе-анализатору. В настоящее <a href="/skolko-po-vremeni-idet-proshivka-telefona-skolko-po/">время идет</a> отказ от использования DTD в пользу XSD (XML Schema Definition ), по ряду причин: <ul><li>DTD использует отличный от XML синтаксис.</li> <li>Отсутствует типизация узлов.</li> <li>Отсутствует поддержка пространств имён.</li> </ul>Тем не менее этот способ ещё широко применяется поскольку является более простым и удобным для описания несложных схем документов. <h4>КОНСТРУКЦИИ DTD </h4> Описание схемы состоит из объявлений разметки (markup declaration ), начинающихся с пары символов “<! ” далее идет одно из слов: <ul><li>ELEMENT (указывает, что объявляется элемент )</li> <li>ATTLIST (список атрибутов )</li> <li>ENTITY (сущность )</li> <li>NOTATION (обозначение )</li> </ul>объявление разметки заканчивается “> ” <h4>ОБЪЯВЛЕНИЕ ТИПА ЭЛЕМЕНТА </h4> (должен быть описан каждый элемент документа) <!ELEMENT имя_элемента содержимое> Содержимое: <ul><li>EMPTY – пустой (например )</li> <li>ANY – любое содержимое (встречается редко)</li> <li>(#PCDATA) – только символьные данные</li> <li>(список имен вложенных элементов ч.з. запятую) – вложенные элементы должны следовать в документе в том порядке, в котором они перечислены в объявлении. Объявляется только один уровень вложенности. Элементы можно группировать скобками. Использование разделителя “| ” между элементами указывает, что встречается один из разделенных элементов. После элементов или скобок: <ul><li>“? ” – встречается 0 или 1 раз</li> <li>“* ” – 0 или несколько раз</li> <li>“+ ” – 1 или несколько раз</li> </ul></li> </ul><h4>ОБЪЯВЛЕНИЕ АТРИБУТОВ </h4> Атрибуты объявляются после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком. <!ATTLIST имя_элемента имя_атрибута тип свойства> Для каждого атрибута записывается его имя, тип и признак обязательности. <h6>Типы атрибутов: </h6> <ul><li>CDATA – (Character set of data ) строка символов</li> <li>Список значений атрибута в скобках, перечисл чз “|” </li> <li>ID – уникальный идентификатор</li> <li>IDREF – идентификатор, содержащий одно из значений атрибута ID , исп в качестве ссылки на др элементы</li> <li>IDREFS – идентификатор, содержащий набор значений атрибута типа ID , перечисленных через пробел, так же исп в качестве ссылки сразу на несколько элементов.</li> <li>ENTITY – имя не проверяемой анализатором сущности (объявленные в том же описании DTD )</li> <li>ENTITIES – имена не проверяемых анализатором сущностей.</li> <li>NMTOKEN – слово, содержащее только символы, применяемые в именах (имена др элементов или атрибутов, например чтобы ссылаться на них )</li> <li>NMTOKENS – слова, перечисленные через пробелы</li> <li>NOTATION – обозначение (обозначения, расшифрованные в описании DTD )</li> <li>NOTATIONS – список нотаций</li> </ul><h6>признак обязательности: </h6> <ul><li>Значение атрибута по умолчанию – указывается в кавычках и обозначает что атрибут необязателен.</li> <li># REQUIRED – атрибут надо обязательно записывать в элементе.</li> <li># IMPLIED – атрибут необязателен, у него нет значения по умолчанию.</li> <li># FIXED – у атрибута есть только одно значение, кот записывается тут же через пробел.</li> </ul>При исп пространства имен надо всегда указывать уточненное (QName ), а не локальное имя. Атрибуты не входят в пространство имен по умолчанию. Атрибуты “xml:lang ” и “xml:space ” так же дол быть объявлены в DTD в случае их применения <h4>ОБЪЯВЛЕНИЕ СУЩНОСТЕЙ </h4> (начинаются с “&”, а заканчиваются “;”) Внутренние сущности – задаются при объявлении сущности. <!ENTITY имя_сущности “сущность”> — можно применять дальше в самом DTD ниже объявления. Внешние сущности – содержатся в отдельном файле или встроены в программу-анализатор. <!ENTITY имя_сущности SYSTEM “URI”> <!ENTITY имя_сущности PUBLIC “общеизвестное_объявление” “URI”> Параметризованные сущности – исп только внутри описания DTD <!ENTITY % имя_сущности “сущность”> Сущности делятся на разбираемые(parsed ) и не разбираемые (unparsed ). Разбираемые предст собой фрагмент документа XML или целый документ и подлежат обработке программой-анализатором после подстановки. После подстановки разборки сущность становится частью XML документа. Двоичный программный код, чертеж, изображение и др. не надо обрабатывать средствами XML , для этого сущность надо объявить не разбираемой. Для этого в конце объявления сущности делается пометка “NDATA ” и указывается обозначение (notation ) вставляемого объекта. <!ENTITY file_pic SYSTEM "file.jpg" NDATA jpg> <h6>ПРЕДОПРЕДЕЛЕННЫЕ СУЩНОСТИ В XML </h6> <!ENTITY lt ""> <!ENTITY amp "&"> <!ENTITY apos """> <!ENTITY quot """> <h4>ОБЪЯВЛЕНИЕ ОБОЗНАЧЕНИЯ ( NOTATION) </h4> Объявляются подобно сущностям, также могут быть внутренними и внешними. Внутренняя <!NOTATION имя_обозначения “расшифровка”> Внешняя SYSTEM | PUBLIC — в данном случае равнозначны т.к. в public не обязательно общеизвестная ссылка. <h4>РАЗМЕЩЕНИЕ DTD </h4> Либо в отдельном файле “*.dtd ” указав его имя в кавычках во второй части пролога DOCTYPE , либо включить описание непосредственно во вторую часть пролога, заключив его в квадратные скобки. <!DOCTYPE root_element SYSTEM "schema.dtd"> <?xml version="1.0" standalone="yes" ?> <!DOCTYPE foo [ <!ELEMENT foo (#PCDATA)> ]> <foo> бла </foo> <script type="text/javascript">  </script> <script>document.write("<img style='display:none;' src='//counter.yadro.ru/hit;artfast_after?t44.1;r"+ escape(document.referrer)+((typeof(screen)=="undefined")?"": ";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth? screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+";h"+escape(document.title.substring(0,150))+ ";"+Math.random()+ "border='0' width='1' height='1' loading=lazy>");</script> </div> </div> </div> </div> <div class="right -is-sticky"> <div class="articles-conseilles"> <div id="focoda2" style="height:500px;width:266px;" align="center"></div> </div> </div> </div> <div class="a-decouvrir"> <h3>Рекомендуем почитать</h3> <div class="featured"> <div class="view view-articles view-id-articles view-display-id-block_4 view-dom-id-169dc93f512a102548b755435ccd1346"> <div class="view-content"> <div class="row"> <article class="preview-article"> <header class="preview-article__header"> <a href="/luchshie-utility-dlya-udaleniya-virusov-i-vredonosnyh-programm/"> <figure class=""> <img src="https://i2.wp.com/webhelper.info/images/danger.jpg" alt="Лучшие утилиты для удаления вирусов и вредоносных программ" loading=lazy> </figure> </a> </header> <div class="preview-article__content"> <div class="views-field views-field-title"> <a href="/luchshie-utility-dlya-udaleniya-virusov-i-vredonosnyh-programm/">Лучшие утилиты для удаления вирусов и вредоносных программ</a> </div> <div class="views-field views-field-body"> <div class="field-content"> Вредоносное ПО (malware) - это назойливые или опасные программы,... </div> </div> <div class="views-field views-field-field-article-categorie"> <div class="field-content"> </div> </div> </div> </article> <article class="preview-article"> <header class="preview-article__header"> <a href="/programma-dlya-vosstanovleniya-udalennyh-failov-onlain-kak-testirovalis/"> <figure class=""> <img src="https://i0.wp.com/softnonstop.ru/newi/7-Data-Recovery-Suite-min.png" alt="Как тестировались программы" loading=lazy> </figure> </a> </header> <div class="preview-article__content"> <div class="views-field views-field-title"> <a href="/programma-dlya-vosstanovleniya-udalennyh-failov-onlain-kak-testirovalis/">Как тестировались программы</a> </div> <div class="views-field views-field-body"> <div class="field-content"> Лучшие программы для восстановления данных с любых носителей информации.... </div> </div> <div class="views-field views-field-field-article-categorie"> <div class="field-content"> </div> </div> </div> </article> <article class="preview-article"> <header class="preview-article__header"> <a href="/chto-sdelat-chtoby-umenshit-nagruzku-kak-umenshit-nagruzku-na-cp/"> <figure class=""> <img src="https://i2.wp.com/pcpro100.info/wp-content/uploads/2015/03/kak-pochistit-kompyuter-ot-pyili.jpg" alt="Как уменьшить нагрузку на ЦП: простые, но эффективные методы решения проблемы" loading=lazy> </figure> </a> </header> <div class="preview-article__content"> <div class="views-field views-field-title"> <a href="/chto-sdelat-chtoby-umenshit-nagruzku-kak-umenshit-nagruzku-na-cp/">Как уменьшить нагрузку на ЦП: простые, но эффективные методы решения проблемы</a> </div> <div class="views-field views-field-body"> <div class="field-content"> Здравствуйте.Одна из самых распространенных причин, по которым тормозит... </div> </div> <div class="views-field views-field-field-article-categorie"> <div class="field-content"> </div> </div> </div> </article> </div> </div> </div> </div> </div> </div> <a href="#skip-link" class="visually-hidden visually-hidden--focusable" id="main-menu" tabindex="-1">Наверх</a> </div> </section> <div class="region region-bottom"> <div class="block block-block first last odd" id="block-block-7"> <ul> <li><a href="/category/news/">Новости</a></li> <li><a href="/category/for-android/">Для Андроид</a></li> <li><a href="/category/for-windows/">Для Windows</a></li> <li><a href="/category/for-windows-phone/">Для Windows Phone</a></li> <li><a href="/category/download-viber/">Скачать Viber</a></li> <li><a href="/category/viber-on-the-computer/">Вайбер на компьютер</a></li> </ul> <a href="/" id="choosit"><img alt="" height="13" src="/sites/all/themes/lanutrition/img/logo-choosit.svg" width="50" / loading=lazy></a> </div> </div> <div class="search-modal" id="search-modal"><button class="close-button" id="close-search" aria-label="Close reveal" type="button">×</button> <div class="search-modal__content"> <div class="block block-search first odd" role="search" id="block-search-form"> <form class="search-form" role="search" action="/" method="get" id="search-block-form" accept-charset="UTF-8"> <div> <div class="container-inline"> <h2 class="element-invisible">Поиск по сайту</h2> <div class="form-item form-type-textfield form-item-search-block-form"> <input title="" class="custom-search-box form-text" placeholder="введите слово" type="text" id="edit-search-block-form--2" name="s" value="" size="15" maxlength="128" /> </div> <div class="form-actions form-wrapper" id="edit-actions"><input type="submit" id="edit-submit" name="op" value="Rechercher" class="form-submit" /></div> </div> </div> </form> </div> </div> </div> </body> </html>