<!ELEMENT team(coach+, player*, assistant?)>
В этом примере указывается, что внутри элемента <team> должны быть определены элементы coach, player и assistant, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент player может встречаться несколько раз, а элемент assistant является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :
<!ELEMENT flower (PCDATA | title )*>
Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться. Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом "|" список элементов. Пример корректного XML- документа:
<?xml version="1.0"?><! DOCTYPE team [<!ELEMENT team (title,coach+, player*, assistant?)><!ELEMENT coach (name|PCDATA)><!ELEMENT name PCDATA><!ELEMENT player (name, nationality)><!ELEMENT nationality PCDATA><!ELEMENT l_name PCDATA>]>...<team><coach><f_name>John</ f_name>< l_name>Dixon</ l_name></coach> < player number="1">< f_name >Jorge</ f_name><l_name>Woods</l_name><nationality>English</ nationality></ player>…</team>Определение атрибутов
Списки атрибутов элемента определяются с помощью ключевого слова !ATTLIST. Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <player> могут быть определены следующие атрибуты:
<!ATTLIST playernumber ID #REQUIREDtype (goalkeeper | back | halfback | forward) #IMPLIED >В данном примере для элемента player определяются три атрибута: number и type, которые имеют типы ID(идентификатор) и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:
· CDATA - содержимым документа могут быть любые символьные данные
· ID - определяет уникальный идентификатор элемента в документе
· IDREF(IDREFS) - указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
· ENTITY(ENTITIES - значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе
· NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)
· Список допустимых значений - определяется список значений, которые может иметь данный атрибут.
Также в определении атрибута можно использовать следующие параметры:
· #REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
· #IMPLIED - атрибут не является обязательным
· #FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
· Значение - задает значение атрибута по умолчанию
Определение компонентов(макроопределений)
Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD-компоненты при помощи инструкции !ENTITY:
<!ENTITY hello ' Мы рады приветствовать Вас!' >Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD-компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку "Мы рады приветствовать Вас"
В общем случае, внутри DTD можно задать три типа макроопределений:
Внутренние макроопределения - предназначены для определения строковой константы, с их помощью можно организовывать ссылки на часто изменяемую информацию, делая документ более читабельным. Внутренние компоненты включаются в документ при помощи амперсанта &
В XML существует пять предустановленных внутренних символьных констант:
· < - символ "<"
· > - символ ">"
· & - символ "&"
· ' - символ апострофа "'"
· " - символ двойной кавычки """
Внешние макроопределения - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования макроса будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются и используются внешними программами
<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD-правила
Например, для следующего фрагмента документа:
<!ELEMENT title (PCDATA)><!ELEMENT name (PCDATA)><!ELEMENT nationality (PCDATA)><!ELEMENT coach (PCDATA | name)><!ELEMENT player ((PCDATA | name), nationality)><!ELEMENT team (title,coach, player*)>можно использовать более короткую форму записи:
<!ELEMENT name (PCDATA)><! ENTITY %names 'PCDATA | name'><!ELEMENT coach (%names;)><!ELEMENT player (%names, nationality)><!ENTITY %content 'coach | (player*)'><!ELEMENT team (title,%content;)>Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:
<!ENTITY %teamattr 'country #REQUIRED CDATA '><!ENTITY %playerattr "number ID #IMPLIED type CDATA, type (goalkeeper | back | halfback | forward) #IMPLIED CDATA'><!ELEMENT team (title,coach, player*,assistant?)><!ATTLIST team %teamattr;><!ELEMENT player (name, nationality)><!ATTLIST player %playerattr;>Типизация данных
Довольно часто при создании XML-элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент <last-modified>10.10.98</last-modified>, то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL-запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос. Если в качестве программы на стороне клиента используется верифицирующий XML-процессор, то информацию о типе можно передавать при помощи специально созданного для этого атрибута элемента, имеющего соответствующее 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>100 р. 00 к.</price></house>...Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD.
DTD весьма удобный механизм осуществления контроля за содержимым документа. На сегодняшний день, практически все программы просмотра документов Интернет используют DTD-правила. Однако это не единственный способ проверки корректности документа. В настоящий момент в W3 консорциуме находится на рассмотрении новый стандарт языка описания структуры документов, называемый схемами данных.