DTD - Атрибуты. Введение в XML DTD

30.07.2019 Разное

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

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

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

...

Внутри же документа DTD- декларации включаются следующим образом:

... ... ]> ...

В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML - процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes" , то использование внешних DTD описаний будет запрещено.

Определение элемента

Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

Например, для элемента можно определить следующее правило:

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

В определении элемента мы указываем сначала название элемента(flower) , а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY ,ANY . Первая указывает на то, что элемент должен быть пустым(например, ), вторая - на то, что содержимое элемента специально не описывается.

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

В этом примере указывается, что внутри элемента должны быть определены элементы title , author и table-of-contents , причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :

Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться.

Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA , а затем разделенный символом "|" список элементов.

Пример корректного XML - документа:

]> ...
Marks avenue
12-12-12 46-23-62 [email protected]

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента

могут быть определены следующие атрибуты:

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

  • CDATA - содержимым документа могут быть любые символьные данные
  • ID - определяет уникальный идентификатор элемента в документе
  • IDREF (IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
  • ENTITY (ENTITIES ) - значение атрибута должно быть названием(или списком названий, если используется ENTITIES ) компонента (макроопределения), определенного в документе
  • NMTOKEN (NMTOKENS ) - содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA )
  • Список допустимых значений - определяется список значений, которые может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

  • #REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
  • #IMPLIED - атрибут не является обязательным
  • #FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
  • Значение - задает значение атрибута по умолчанию

Определение компонентов(макроопределений)

Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD - компоненты при помощи инструкции !ENTITY :

Программа-анализатор, просматривая в первую очередь содержимое области DTD - определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD - компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello ; , которое будет заменено на строчку " Мы рады приветствовать Вас"

В общем случае, внутри DTD можно задать три типа макроопределений:

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

В XML существует пять предустановленных внутренних символьных констант:

  • < - символ "<"
  • > - символ ">"
  • & - символ "&"
  • " - символ апострофа """
  • " - символ двойной кавычки """

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

Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом % , вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD - правила

Например, для следующего фрагмента документа:

можно использовать более короткую форму записи:

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

Типизация данных

Довольно часто при создании XML - элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL - запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL -запрос.

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

Задав атрибуту значение по умолчанию LONG и определив его как FIXED , мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD - определении.

Вот пример XML - документа, в котором определяются и используются несколько элементов с различными типами данных:

... 5 2 32.5 true 18346 34 р. 28 к. ...

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

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

20. Языки описания cхем XML

DTD схемы. Недостатки DTD схем. XDR схемы. Элементы и атрибуты XDR схем.

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

    описать, что именно является разметкой;

    описать точно, что означает разметка.

Наиболее известными языками описания схем являются следующие:

    DTD (Document Type Definition) - язык определения типа документов, который первоначально использовался в качестве язык описания структуры SGML-документа.

    XDR (XML Data Reduced) – диалект схемы XML, разработанный Microsoft, который поддерживался в Internet Explorer 4 и 5 версий.

    XML Schema или просто XSD (язык определения схем XML) – рекомендация консорциума W3C с 2001 года.

Рассмотрим подробнее первые два из них. Третий язык описания схем рассматривается в лабораторной работе 11.

DTD схема

Схема DTD предоставляет шаблон разметки документа, в котором указываются наличие, порядок следования и расположение элементов и их атрибутов в документе XML.

В рамках DTD модель содержимого XML документа можно описать следующим образом:

Каждый элемент документа может иметь один из типов:

Синтаксис

Комментарий

Содержит только текстовые данные

Другие элементы

Содержит только дочерние элементы

Смешанное

Содержит комбинацию текстовых данных и дочерних элементов

Ничего не содержит

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

имя_элемента имя_атрибута1 (тип) значение_по_умолчанию

…………………………………………………………………………………...

имя_элемента имя_атрибутаN (тип) значение_по_умолчанию >

При этом атрибут в DTD может иметь один из трех типов:

  • Маркированные атрибут

    Атрибута с перечислением

Кроме типа атрибута можно также задавать и его модальность:

Рассмотрим в качестве примера описание атрибутов строкового типа для элемента, описывающего некоторое сообщение:

number CDATA #REQUIRED

date CDATA #REQUIRED

from CDATA #FIXED

status CDATA #IMPLIED>

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

number ID #REQUIRED

from CDATA #REQUIRED

alert (low | normal | urgent) "normal">

Маркированных атрибуты элемента могут быть четырех типов:

И, наконец, в DTD можно использовать следующие индикаторы вхождения последовательностей:

Символ

Пример

Описание

Последовательное использование элементов списка

Используется один из членов списка

Используется один и только один элемент

Необязательное использование (0 или 1 раз)

Используется один или несколько раз

Используется ноль или несколько раз

В качестве примера приведем DTD схему, описывающую структуру электронного почтового ящика:

Исходный XML документ, удовлетворяющий данной схеме, может выглядеть, например, так:

[email protected]

[email protected]

Re:

[email protected]

[email protected]

Remind

[email protected]

Remind me about meeting.

Обратите внимание на 2-ю строчку документа, в которой указывается внешняя ссылка на файл, содержащий DTD схему.

В принципе, DTD допускает два способа использования в XML документе.

Объявление внутренней схемы:

Объявление внешней схемы:

В заключение укажем на следующие недостатки DTD схем:

    Не являются экземплярами XML. Требуется изучение совершенно другого языка.

    Не предоставляют контроль за типами данных, за исключением самых простых текстовых данных.

    Не являются экземплярами XML, поэтому их нельзя легко расширить или преобразовать к другим языкам разметки – HTML или DHTML.

    Не обеспечивают поддержки пространств имен XML.

XDR схема

XML-Data – полное имя языка описания схем, предложенного Майкрософт, а XML-DataReduced– это "часть" полной рекомендации. Схема XDR - это экземпляр XML, т.е. соответствует всем синтаксическим правилам и стандартам XML.

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

Корневым элементом в схеме XDR всегда является элемент Schema:

name="имя_схемы" xmlns="urn:schemas-microsoft-com:xml-data"

xmlns:dt="urn:schemas-microsoft-com:datatypes">

<-- Объявления других элементов -->

Элемент ElementType имеет синтаксис:

content="{empty | texOnly | eltOnly | mixed}">

dt:type "datatype"

model="{open | closed}"

order="{one | seq | many}"

Элемент ElementType может иметь следующие атрибуты:

Имя атрибута

Описание

Имя элемента

Тип данных элемента

Может принимать значения:

Open – разрешено использовать элементы, не определенные в схеме

Closed – запрещено использовать элементы, не определенные в схеме

Порядок следования дочерних элементов в экземпляре XML. Допустимые значения:

one – предполагается наличие одного документа

many – любое количество элементов в любом порядке

seq – элементы указываются в строго заданном порядке.

качестве дочерних элементов для ElementType можно использовать следующие:

Имя элемента

Описание

Объявляет дочерний элемент

Обеспечивает описание элемента ElementType

Обеспечивает тип данных элемента ElementType

Определяет порядок следования элементов

Определяет атрибут

Определяет сведения о дочернем элементе AttributeType

Для объявления атрибутов используется синтаксис:

default="default-value"

dt:type="primitive-type"

dt:values="enumerated-values"

required="{yes|no}"

В свою очередь элемент AttributeType может иметь атрибуты:

Значение

Описание

Значение по умолчанию

Один из следующих типов:

entity, entities, enumeration, id, idref, nmtoken, nmtokens, notation, string

Допустимые значения

Имя атрибута

Указывает на обязательное наличие атрибута в описании

Синтаксис для описания элемента attribute выглядит следующим образом:

default="default-value"

type="attribute-type"

а его возможные значения могут быть такими:

Значение

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

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

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

Итак, начнем.

Что такое DTD в XML и для чего он нужен

Если говорить кратко, то DTD в XML используется для проверки грамматики документа и соответствия его стандарту (тому, который придумал разработчик или вы сами). Это позволяет парсеру (обработчику) на этапе обработки определить, соответствует ли документ нашим требованиям. То есть, проходит валидация XML-документа.

Необходимость проверки грамматики XML-документов заключается в следующем:

  • XML-документ может быть предназначен не для вашей системы.
  • XML-документ может содержать неправильные данные.
  • XML-документ может содержать ошибки в структуре ().

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

Недостатки XML DTD

  • Отличный от XML синтаксис языка. Это вызывает множество проблем, таких как, например, проблемы с кодировкой или невозможность отслеживать ошибки.
  • Нет проверки типов данных. В DTD есть только один тип – строка.
  • В DTD нет . Нельзя поставить в соответствие документу два и более DTD описаний.

Это был краткий список недостатков DTD, которые с успехом исправлены в XML схемах, о которых мы поговорим в следующих статьях.

Объявление элементов, атрибутов и сущностей в DTD. Модификаторы «*», «?», «+»

Для объявления элементов, атрибутов и сущностей в DTD используются специальные декларации и модификаторы. Чтобы подробно во всем разобраться, давайте для начала рассмотрим теоритическую информацию, а затем во второй части статьи перейдем к практическим примерам.

Определение элемента XML и последовательности элементов XML

Элемент book содержит по одному элементу title, author, price и description.

Альтернативы элементов

Элемент pricelist содержит элементы title, price и один элемент из трех на выбор – author, company либо sample.

Пустые элементы

Элемент none должен быть пустым.

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

Элемент pricelist может содержать два атрибута – атрибут id и атрибут name. При этом атрибут id является обязательным, так как указано #REQUIRED, а атрибут name – не обязательным (указано #IMPLIED). В свою очередь CDATA указывает обработчику, что разбирать содержимое атрибутов не нужно.

Определение сущностей

Если встретится сущность «&myname;», то вместо нее автоматически подставится «Дмитрий Денисов».

Модификаторы (объясняют повторения элементов)

* — ноль или много.
? – ноль или один.
+ — один или много.

Элемент books может содержать один или более элементов book.

Теперь давайте рассмотрим, как это все выглядит на более практических примерах.

Создание DTD-файла для валидации XML-документа на примере прайс-листа книг

Пусть у нас будет все тот же прайс-лист книг, который мы используем для примеров практически в каждой статье про XML. Сам XML-документ будет выглядеть примерно следующим образом.

Книга 1 &myname; Цена 1 Описание

Конечно, вышеприведенный пример не является пределом мечтаний, но для примера вполне сойдет. Как видно с примера, у нас есть корневой элемент pricelist, который содержит вложенные элементы book. Внутри элементов book находятся элементы title, author, price и возможно description, которые могут содержать какие-то текстовые данные.

Для валидации данного прайс-листа мы можем использовать DTD-документ следующего содержания.

Теперь разберем все более подробно.

  • — декларируем корневой элемент books и в скобках указываем, что он может содержать. В данном случае он может содержать один или более элементов book (плюсик означает один или более, см. выше).
  • — определяем элемент book. Элемент book может содержать один элемент title, один или более элементов author (плюсик), один элемент price и один или ни одного элемента description (знак вопроса).
  • — определяем элемент title. В качестве содержимого элемента указываем #PCDATA. Это означает, что анализатор обязан разбирать то, что находится внутри этого элемента.
  • Аналогичным образом определяем элементы author, price, description.
  • — определяем сущность. Сначала пишем саму сущность, а затем в кавычках то, что будет выводиться на ее месте. По умолчанию в XML определено только 3 сущности. Это больше («>» — <), меньше («<» — >) и амперсанд («&» — &). При желании вы можете создать неограниченное количество сущностей, используя данный способ. В качестве значений могут быть не только слова, но и целые предложения значительного объема.
Подключение DTD для валидации XML-документов

Декларативный способ

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

где вместо DOCUMENT указываем корневой элемент XML-документа.

Для наглядности рассмотрим пример готового самодостаточного документа с декларативным способом включения DTD.

]>

Внешнее определение DTD — подключение DTD-документа

Суть данного метода состоит в том, чтобы подключить к XML-документу файл DTD при помощи следующей конструкции.

где DOCUMENT – указываем корневой элемент XML-документа.
file.dtd – ссылка на файл DTD.

Для наглядности рассмотрим следующий пример.

XML-документ

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

На этом все. Удачи вам и успехов в изучении XML!

Главный писатель по вопросам технологий

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

До того, как вы сможете открыть файл DTD, вам необходимо выяснить, к какому виду файла относится расширения файла DTD.

Tip: Incorrect DTD file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.

Ответ:

Файлы DTD имеют Файлы данных, который преимущественно ассоциирован с DesignTools 2D Design (TechSoft UK Limited).

Файлы DTD также ассоциированы с ArcView UNIX Hyperhelp Supporting File (ESRI), SGML Document Definition File и FileViewPro.

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

Как открыть ваш файл DTD:

Самый быстрый и легкий способ открыть свой файл DTD - это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла DTD.

В случае, если ваш файл DTD не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями DTD.

Если ваш ПК открывает файл DTD, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов DTD с неверной программой.

Установить необязательные продукты - FileViewPro (Solvusoft) | | | |

DTD Multipurpose Internet Mail Extensions (MIME):

  • mime text/xml

DTD Инструмент анализа файлов™

Вы не уверены, какой тип у файла DTD? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

Теперь можно мгновенно получить всю необходимую информацию о файле DTD!

Революционный DTD Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле DTD. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

Чтобы начать бесплатный анализ файла, просто перетащите ваш файл DTD внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла DTD будет показан внизу, прямо в окне браузера.

Перетащите файл DTD сюда для начала анализа

Просмотреть мой компьютер »

Пожалуйста, также проверьте мой файл на вирусы

Ваш файл анализируется... пожалуйста подождите.

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

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

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

...

Внутри же документа DTD- декларации включаются следующим образом:

... ... ]> ...

В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML- процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes ", то использование внешних DTD описаний будет запрещено.

Определение элемента

Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

Например, для элемента можно определить следующее правило:

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

В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA(что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, ), вторая - на то, что содержимое элемента специально не описывается.

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

В этом примере указывается, что внутри элемента должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :

Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться.

Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом "|" список элементов.

Пример корректного XML- документа:

]> ...

Marks avenue
12-12-12 46-23-62 [email protected]

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента

могут быть определены следующие атрибуты:

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

  • CDATA - содержимым документа могут быть любые символьные данные
  • ID - определяет уникальный идентификатор элемента в документе
  • IDREF(IDREFS)- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
  • ENTITY(ENTITIES) - значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе
  • NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)
  • Список допустимых значений - определяется список значений, которые может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

  • #REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
  • #IMPLIED - атрибут не является обязательным
  • #FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
  • Значение - задает значение атрибута по умолчанию

Определение компонентов(макроопределений)

Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD- компоненты при помощи инструкции!ENTITY:

Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку "Мы рады приветствовать Вас"

В общем случае, внутри DTD можно задать три типа макроопределений:

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

В XML существует пять предустановленных внутренних символьных констант:

  • < - символ "<"
  • > - символ ">"
  • & - символ "&"
  • " - символ апострофа """
  • " - символ двойной кавычки """

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

Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD- правила

Например, для следующего фрагмента документа:

можно использовать более короткую форму записи:

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

Типизация данных

Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98, то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении.

Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

... 5 2 32.5 true 18346 34 р. 28 к. ...

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

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