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

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

<!ENTITY hello ' Мы рады приветствовать Вас!' >

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

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

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

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

· &lt; - символ "<"

· &gt; - символ ">"

· &amp; - символ "&"

· &apos; - символ апострофа "&apos;"

· &quot; - символ двойной кавычки """

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

<!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 консорциуме находится на рассмотрении новый стандарт языка описания структуры документов, называемый схемами данных.

Схемы данных

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

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

<schema id="TeamSchema"> <elementType id="#namee"> <string/> </elementType> <elementType id="player"> <element type="#name"/> <attribute name="number"/> <attribute name="type"/> </elementType> <elementType id="team"> <element type="#player"/> <attribute name=”title”/> </elementType> </schema>                   

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

<team title=”Celtics”> <player number="1" type=”goalkeeper”><name>John Ree</ name></ player> <player number="2" type=”back”><name>Peter Loyd</ name></ player> <player number="2" type=”forward”><name>Emil McGeer</ name></ player> </ team >             

Все конструкции языка схем описываются правилами "XML DTD for XML-Data-Schema".

Область схемы данных

Создавая схемы данных, мы определяем в документе специальный элемент, <schema>; внутри которого содержатся описания правил:

<schema id="OurSchema"> <!-- последовательность инструкций --> </schema>

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

<?XML version='1.0'?> <?xml:namespace href="http://www.mrcpk.nstu.ru/schemas/" as="s"/?> <s:schema id="OurSchema"> <!-- последовательность инструкций --> </s:schema>

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

Для определения класса элемента, к которому в дальнейшем будут применяться инструкции, описывающие его содержимое и структуру, предназначен специальный элемент схемы elementType. Название элемента задается атрибутом id. Все дальнейшие инструкции, которые относятся к описываемому классу, определяют его внутреннюю структуру и набор допустимых данных, содержатся внутри блока, заданного тэгами <elementType> и </elementType>. При определении класса элемента, можно также использовать комментарии к нему, которые заключаются в тэги < descript></descript>

 

Атрибуты элемента

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

<elementType id="player"> <attribute name="number"/> … </elementType>

В данном примере элементу <p layer> определяется атрибут number, значением которого может быть любая последовательность разрешенных символов:

< player number ="0"/> < player number =" some text "/>

Подобно DTD, схемы данных позволяют устанавливать ограничения на значения и способ использования атрибутов. Для этого в дескрипторе <attribute> необходимо использовать параметр atttype. Например, если мы хотим указать, что значение атрибута должно использоваться программой-анализатором как уникальный идентификатор, то нам необходимо создать следующее правило:

<elementType id="player"> <attribute name="number" atttype="ID"/> </elementType>

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

<attribute name="type" atttype="ENUMERATION" values="goalkeeper back halfback forward" >

Модель содержимого элемента

Под моделью содержимого в схеме данных понимают описание всех допустимых объектов XML-документа, использование которых внутри данного элемента является корректным. Модель содержимого определяется инструкциями, расположенными внутри блока <elementType>. Вложенные элементы описываются при помощи инструкции element, в которой параметром type указывается класс объекта - ссылка на его определение:

<elementType id="player"> <element type="#name"/> <element type="# nationality "/> </elementType>

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

<elementType id="player"> <element type="#name" occurs="REQUIRED"/> <element type="#nationality" occurs="OPTIONAL"/> <element type="#clubs" occurs="ONEORMORE"/> </elementType>

Возможные значения этого параметра таковы:

· REQUIRED - элемент должен быть обязательно определен

· OPTIONAL - использование элемента не является обязательным

· ZEROORMORE - вложенный элемент может встречаться несколько раз или ни разу

· ONEORMORE - элемент должен встречаться хотя бы один раз

Примеры правильных XML-документов, использующих приведенную выше схему:

< player > <name>John Ree</name> < nationality > English </ nationality > <clubs>Celtics</clubs> <clubs>Portsmut</clubs> </ article >

или

<player> <name>John Ree</name> <clubs>Celtics</clubs> < clubs > Portsmut </ clubs > </ article >

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

· <string/> - указывает на то, что содержимым элемента является только свободная текстовая информация(секция PCDATA):

<elementType id="name"> <string/> </elementType>

· <any/> - указывает на то, что содержимым элемента должны являться только элементы, без текста, незаключенного ни в один элемент:

<elementType id="coach"> <any/> </elementType>

· <mixed> - любое сочетание элементов и текста

<elementType id="player"> <mixed/> </elementType>

· <empty> - пустой элемент.

Группировка элементов

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

<elementType id="team"> <element type="#title" occurs="REQUIRED"/> <group occurs="OPTIONAL"> <element type="#player"> <element type="#assistant"> </group> </elementType>

Группировка объектов позволяет определять сразу группу объектов различных типов, которые могут находится внутри данного объекта. В приведенном примере мы указали, что внутри объекта типа conteam могут быть включены элементы t itle, player, и assistant, причем атрибутом occurs мы указали, что элементы в группе являются необязательными. Корректным для таких схем будут являться следующие фрагменты документов:

<team> <title>Celtics</tel> <player> … </player> <assistant> … </assistant> </team>... <team> <title>Celtics</tel> </team>... <team> <title>Celtics</tel> <player> … </player> </team>

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

<elementType id="team"> <element type="#title" occurs="REQUIRED"> <group groupOrder="AND" occurs="OPTIONAL"> <element type="#player"> <element type="#assistant"> </group> </elementType>

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

< team > <title>Celtics</tel> <player> … </player> <assistant> … </assistant> </team>

или

<team> <title>Celtics</tel> <player> … </ player > </ team >