Язык XML. Язык запросов X-Query

 <company-name>AT&amp;T</company-name>

Полный список предопределённых сущностей  состоит из &amp; («&»), &lt; («<»), &gt; («>»), &apos; («'»), и &quot; («"») — последние две полезны для записи разделителей внутри значений атрибутов. Определить свои сущности можно в DTD-документе. Иногда бывает необходимо определить неразрывный пробел, который в XML записывается &#160;

Cсылка по номеру символа (англ. numeric character reference) выглядит как ссылка  на сущность, но вместо имени  сущности указывается символ # и  число (в десятичной или шестнадцатеричной  записи), являющееся номером символа  в кодовой таблице Юникод. Это обычно символы, которые невозможно закодировать напрямую, например буква арабского алфавита в ASCII-кодированном документе. Амперсанд может быть представлен следующим образом:

<company-name>AT&#038;T</company-name>

Директивы анализатора

Инструкции, предназначенные для  анализаторов языка, описываются в XML документе при помощи специальных  тэгов - <? и ?>;. Программа клиента использует эти инструкции для управления процессом разбора документа. Наиболее часто инструкции используются при определении типа документа (например, <? Xml version=”1.0”?>) или создании пространства имен.

CDATA

Чтобы задать область документа, которую  при разборе анализатор будет рассматривать как простой текст, игнорируя любые инструкции и специальные символы, но, в отличии от комментариев, иметь возможность использовать их в приложении, необходимо использовать тэги <![CDATA] и ]]>. Внутри этого блока можно помещать любую информацию, которая может понадобится программе- клиенту для выполнения каких-либо действий (в область CDATA, можно помещать, например, инструкции JavaScript). Естественно, надо следить за тем, чтобы в области, ограниченной этими тэгами не было последовательности символов ]].

Определение типа   документа(DTD)

DTD (англ. Document Type Definition - определение типа документа) — язык описания структуры XML-документа.

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

...

]>

...

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

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

Элемент в 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 )*>

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

Если в  определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать 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>

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

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

<!ATTLIST article

id ID #REQUIRED

about CDATA #IMPLIED

type (actual | review | teach )  'actual' ''

>

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

CDATA - содержимым документа могут быть любые символьные данные.

ID - определяет уникальный идентификатор элемента в документе.

IDREF (IDREFS) - указывает, что значением атрибута должно выступать название (или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента.

ENTITY (ENTITIES) - значение атрибута должно быть названием (или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе.

NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово (т.е. этот параметр является ограниченным вариантом CDATA).

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

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

#REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа.

#IMPLIED - атрибут не является обязательным.

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

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

Довольно часто при создании 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>34 р. 28 к.</price>

</house>

...

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

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

Во-первых, он использует отличный от XML синтаксис.

Во-вторых, отсутствует типизация узлов.

На смену DTD пришёл стандарт консорциума W3C XML Schema.

Схемы данных

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

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

Внешний вид схем данных

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

<schema id="OurSchema">

<elementType id="#title">

<string/>

</elementType>

<elementType id="photo">

<element type="#title">

<attribute name="src"/>

</elementType>

<elementType id="gallery">

<element type="#photo">

</elementType>

</schema>                        

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

<gallery>

<photo id="1"><title>My computer</title></photo>

<photo id="2"><title>My family</title></photo>

<photo id="3"><title>My dog</title></photo>

</gallery>,

а некорректным этот:

<gallery>

<photo id="1"/>

<photo index="2"><title>My family</title></photo>

<photo index="3"><title> My dog </title><dogname>

Sharik</dogname></photo>

</gallery>                       

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

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

<elementType id="issue">

<descript>Элемент содержит информацию об очередном

 выпуске журнала</descript>