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

Элемент

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

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

Пустой элемент имеет следующий вид:

< имя атрибут1 =" значение1 " атрибут2 =" значение2 " и т.д. />

Примеры

Непустые элементы имеют вид:

< имя атрибут1 =" значение1 " атрибут2 =" значение2 " и т.д. >

 ...

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

...

Пример

  sometext

И в том, и в другом случае, имя задает имя элемента, а конструкции вида атрибутX =" значениеХ " — определяют значения его атрибутов. Имена в XML являются регистро-зависимыми, то есть имена MyElement, myelement и MYELEMENT различаются. Кроме того, имена в XML могут принадлежать различным пространствам имен, о которых мы поговорим чуть позже.

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

Рис. 1.1. Документ и соответствующее ему дерево элементов

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

Обратимся теперь к синтаксису элементов. EBNF-правило, определяющее элемент, выглядит следующим образом:

[39] element ::= EmptyElemTag

                 | STag content ETag

Пустому элементу соответствует нетерминал EmptyElemTag. Непустой элемент начинается открывающим тегом (нетерминал STag), включает некоторое содержимое (content) и заканчивается закрывающим тегом (ETag).

Открывающий тег состоит из имени (Name) и последовательности определений атрибутов (Attribute), которые разделены пробельными символами:

[40] STag ::= '<' Name (S Attribute)* S? '>'

В ряде случаев атрибуты тега могут отсутствовать.

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

<а

 href="http://www.xsltdev.ru"

>

В закрывающем теге имени предшествует косая черта ("/") и перед закрывающей угловой скобкой тоже могут стоять пробелы:

[42] ETag ::= ''

Имена в открывающем и закрывающем тегах должны совпадать.

Содержимое элемента может состоять из элементов (нетерминал element), сущностей (Reference), секций символьных данных (CDSect), инструкций по обработке (PI) и комментариев (Comment), перемешанных с символьными данными (CharData):

[43] content ::= CharData?

                 ((element

                 | Reference

                 | CDSect

                 | PI

                 | Comment) CharData?)*

Пустой элемент не имеет содержимого и задается продукцией EmptyElemTag в следующем виде:

[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'

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

Замечание

Для того чтобы привести синтаксис HTML в соответствие со стандартом XML, был создан язык XHTML. Этот язык полностью соответствует синтаксису XML, что делает возможным обработку XHTML-документов XML-средствами, но при этом набор тегов XHTML идентичен набору тегов языка HTML. К сожалению, далеко не все браузеры поддерживают XHTML. Чаще всего проблемы возникают именно с пустыми элементами (или одиночными тегами в терминах HTML): например, браузеры могут некорректно воспринимать запись вида <br/> . В большинстве случаев проблема решается использованием перед косой чертой пробела: запись вида <br /> , скорее всего, будет обработана корректно.

Атрибут

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

атрибут =" значение "

Например, в записи гипертекстовой ссылки

<а href="http://www.xsltdev.ru">Заходите к нам!

элемент а имеет атрибут href, которому присвоено значение "http://www.xsltdev.ru".

В языке XML атрибуты всегда должны иметь значения. Например, атрибут selected в записи элемента

 выбранный элемент

будет задан с точки зрения XML некорректно, поскольку ему не присвоено значение. Заметим, что в HTML такое определение является вполне нормальным. Такую ошибку легко исправить следующим образом:

 выбранный элемент

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

 выбранный элемент

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

Атрибуту login присвоено значение "scott" (включая двойные кавычки), атрибуту password — значение 'tiger' (включая одинарные кавычки).

В XML один элемент не может иметь атрибуты с одинаковыми именами.

Определение атрибута состоит из имени, за которым следует знак равенства, а затем, значение атрибута:

[41] Attribute ::= Name Eq Attribute

[25] Eq ::= S? '=' S?

[10] AttValue ::= '"' ([^<&"] | Reference)* '"'

                  | "'" ([^<&'] | Reference)* "'"

Значение атрибута записывается в одинарных или двойных кавычках, причем оно не может содержать символов '<' и '&', которые используются в XML как управляющие символы (< открывает тег элемента, а & — сущность). Вместе с тем, значение атрибута может содержать сущность (нетерминал Reference) — специальную конструкцию, о которой мы поговорим чуть позже.

Инструкция по обработке

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

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

Примером инструкции по обработке может послужить следующая запись:

В данном случае целевое приложение имеет имя 'serv', а сама инструкция может быть интерпретирована как указание серверу на то, что документ нужно сохранить в кэше. Естественно, инструкции по обработке имеют смысл только для тех приложений, которым они адресуются.

Продукции инструкций по обработке имеют следующий вид:

[16] PI ::= '

            (S (Char* - (Char* '?>' Char*)))? '?>'

В этом правиле выражение (S (Char* - (Char* '?>' Char*)))? означает, что приложение и содержимое инструкции по обработке разделены пробельными символами, причем содержимое состоит из любых символов, кроме последовательности '?>', которая обозначает конец инструкции.

Целевое приложение может иметь любое имя (кроме "xml" в любом регистре символов). Имя целевого приложения определяется EBNF-правилом PITarget:

[17] PITarget ::= Name - (('X' | 'х') ('М' | 'm') ('L' | 'l'))

В XML определена особая конструкция, называемая ХМL-декларацией (XML declaration). Она имеет вид:

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

Замечание

В отличие от элементов, XML-декларация, как и инструкции по обработке не могут иметь атрибутов. Однако их содержимое очень часто образуется в форме имя =" значение " — такие объявления и называются псевдоатрибутами.

Псевдоатрибут version содержит информацию о версии XML, в соответствии с которой был создан этот документ. Текущей версией языка XML является 1.0, поэтому в большинстве случаев указывается version="1.0".

Пример

Псевдоатрибут encoding сообщает, в какой кодировке создан данный документ. По умолчанию выбрана Unicode-кодировка UTF-8 (подробнее см. "Использование Unicode"), но точно так же может быть использована и любая другая кодировка, лишь бы только ее поддерживало программное обеспечение, обрабатывающее документ.

Пример

Большинство документов, созданных на русском языке, используют кириллические кодировки windows-1251 и KOI8-R; XML-декларации для этих документов будут иметь вид:

и

соответственно.

Для документов, в которых использовались только нижние 127 символов ASCII, то есть, символы с кодами, не превышающими #x7F, псевдоатрибут encoding указывать необязательно. В этой области символов кодировка UTF-8 совпадает с ASCII.

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

Декларации XML соответствует продукция XMLDecl, которая, в свою очередь, использует несколько дочерних правил:

[23] XMLDecl ::= '

                  SDDecl? S? '?>'

Продукция VersionInfo определяет синтаксис псевдоатрибута version:

[24] VersionInfo ::= S? 'version' Eq

                     ("'" VersionNum "'"

                     | "" VersionNum "")

Значение версии документа может состоять из латинских букв и цифр, а также символов "_", ".", ":" и "-":

[26] VersionNum ::= ([a-zA-Z0-9_.:] | '-')+

Кодировка объявляется продукцией EncodingDecl, которая синтаксически похожа на VersionInfo:

[80] EncodingDecl ::= S? 'encoding' Eq

                      ("'" EncName "'"

                      | '"' EncName '"')

Имя кодировки, EncName, может состоять только из латинских букв, цифр и символов ".", "_" и "-", причем первым символом названия кодировки всегда должна быть буква:

[81] EncName [A-Za-z] ([A-Za-z0-9.-] | '-')*

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

□ Windows-1251;

□ KOI8-R;

□ Cp866;

□ ISO-8859-5.

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

Псевдоатрибуту standalone соответствует EBNF-правило SDDecl:

[32] SDDecl ::= S 'standalone' Eq

                (("'" ('yes' | 'no') "'")

                | ( '"' ('yes' | 'no') '"' ) )

Расшифровывается это правило очень просто: псевдоатрибут standalone может иметь значение yes или no, заключенное в одинарные или двойные кавычки.

Секции СDATA

Секции CDATA выделяют части документа, внутри которых текст не должен восприниматься как разметка. CDATA означает буквально "character data" — символьные данные. Секции CDATA задаются следующим образом:

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

Пример

Следующий текст в документе

Покупайте наших слонов!

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

Покупайте наших слонов!]]>

Такая конструкция уже будет воспринята как символьные данные. Другим примером может быть использование символов "<" и "&":

Секции символьных данных задаются четырьмя довольно простыми правилами:

[18] CDSect  ::= CDStart CData CDEnd

[19] CDStart ::= '

[20] CData   ::= Char* - (Char* ']]>' Char*))

[21] CDEnd   ::= ']]>'

Содержимое секции символьных данных, отвечающее продукции CData, может состоять из любых символов, в том числе "<" и "&", которые не будут восприниматься как разметка. Единственное, чего секции CDATA не могут включать — это последовательность "]]>", которая завершает символьную секцию.

Комментарии (comments)

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

Текст комментария может состоять из любых символов, кроме двух минусов

подряд ("--"). Кроме этого, комментарий не должен заканчиваться символом "-" .

Пример комментария:

...

...

Продукция комментария называется в XML Comment и имеет следующий вид:

[15] Comment ::= ''

Выражение ((Char - '-') | ('-' (Char - '-')))* означает, что содержимое комментария не должно оканчиваться на знак "-" или содержать два таких знака последовательно.

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

За время существования XML была создана разметка для большого числа задач. На таких Web-сайтах, как http://www.xml.org, http://www.schema.net и http://www.ebxml.org можно с большой вероятностью найти определения структуры документов для огромного количества предметных областей. Во многих случаях уже созданные схемы помогут сократить этап концептуального моделирования документов.

Часто случается, что различные логические схемы документов используют одни и те же имена элементов в различных смыслах. Это не является проблемой, если в документе используется только одна схема. Но представьте себе ситуацию, когда в одном и том же документе необходимо использовать элементы нескольких различных схем — будет попросту невозможно определить, какой элемент относится к какой схеме, и, вообще, какие схемы были использованы в документе. Для решения этих проблем в XML используются пространства имен (англ. namespaces).

Чтобы различать схемы документов, каждой из них ставится в соответствие уникальный идентификатор ресурса (URI). Две схемы будут считаться тождественными тогда и только тогда, когда их уникальные идентификаторы будут совпадать, поэтому нужно осторожно выбирать URI для создаваемой схемы документа. Очень часто в качестве URI используются URL различных Web-сайтов. Это совсем не означает, что по указанному адресу должно что-либо находиться, просто такой способ практически гарантирует уникальность — вряд ли кому придет в голову использовать адрес чужого сервера в качестве идентификатора своей схемы.

Пример

Уникальный идентификатор языка XSLT, которому посвящена эта книга, имеет вид:

http://www.w3.org/1999/XSL/Transform

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

< префикс : элемент xmlns: префикс =" URI ">

 ...

Пример

В XSLT чаще всего используется префикс xsl, который задается, как правило, следующим образом:

 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

 version="1.0">

 ...

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

 xmlns:www="http://www.w3.org/1999/XSL/Transform"

 version="1.0">

 ...

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

Пример

 <ааа:anotherelement/>

 ...

Принадлежность элементов той или иной схеме определяется не префиксами, а тем, какие уникальные идентификаторы поставлены этим префиксам в соответствие. То есть два элемента с разными префиксами, заданными одинаковыми идентификаторами, будут считаться принадлежащими одной схеме.

Пример

В следующем фрагменте

 xmlns:xslt="http://www.w3.org/1999/XSL/Transform"

 version="1.0">

 ...

элементы stylesheet и template имеют различные префиксы, но, несмотря на это, принадлежат одной и той же схеме.

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

Пример

 xmlns:aaa="http://www.ааа.com"

 xmlns:bbb="http://www.bbb.com"

 xmlns:ccc="http://www.ccc.com">

 ...

Весьма удобной является возможность использования пространства имен по умолчанию. Определение пространства имен в виде

< элемент xmlns="URI">

 ...

позволяет опускать префиксы в именах элементов.

Пример

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

 <ссс:element xmlns:ccc="http://www.ccc.com"/>

 ...

Обратим внимание, что пространство имен по умолчанию может быть изменено повторным использованием атрибута xmlns в дочерних элементах.

Пример

Документ

эквивалентен документу

 xmlns:aaa="http://www.aaa.com"

 xmlns:bbb="http://www.bbb.com"

 xmlns:ccc="http://www.ccc.com">

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

Синтаксические правила, которые описывают определения пространств имен, задаются не в спецификации XML, а в другом документе — в технической рекомендации "Namespaces in XML" (пространства имен в XML), которая доступна по адресу http://www.w3.org/TR/REC-xml-names. Для того чтобы отличать эти продукции от продукций языка XML, мы будет давать им номера вида [NS1], [NS2] и так далее.

Продукция NSAttName описывает имена атрибутов, декларирующих пространства имен:

[NS1] NSAttName       ::= PrefixedAttName | DefaultAttName

[NS2] PrefixedAttName ::= 'xmlns:' NCName

[NS3] DefaultAttName  ::= 'xmlns'

Имя NCName, которое использовалось в правиле PrefixedAttName, — это имя префикса, который будет использоваться для обозначения принадлежности элементов определенному пространству имен. Это имя отличается от имен, которые отвечают продукции Name тем, что оно не может содержать двоеточия:

[NS4] NCName     ::= (Letter | '_') (NCNameChar)*

[NS5] NCNameChar ::= Letter | Digit | '.' | '-' | '_'

                     | CombiningChar | Extender

Расширенные имена

Использование пространств имен значительно изменяет понятие имени. Действительно, если www:template, xsl:template или просто template могут быть одинаковыми именами, то именем в таком случае должна считаться не просто символьная последовательность, которая его составляет, а нечто большее.

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

Пример

Представим себе элемент вида

Расширенное имя этого элемента будет состоять из локальной, части stylesheet и идентификатора пространств имен http://www.w3.org/1999/XSL/Transform.

Расширенные имена считаются совпадающими, если их локальные части равны и, при этом, они относятся к одному пространству имен.

Префикс в расширенном имени может быть опущен. В таком случае идентификатор пространства имен будет либо выбран по умолчанию (если имеется соответствующее объявление), либо будет нулевым.

Для описания имен элементов и атрибутов, которые должны иметь расширенное представление, используется продукция QName:

[NS6] QName ::= (Prefix ':')? LocalPart

Нетерминалу Prefix соответствует префикс имени, который может быть опущен вместе со следующим за ним разделяющим двоеточием, LocalPart соответствует локальной части имени.

[NS7] Prefix    ::= NCName

[NS8] LocalPart ::= NCName

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

В первой версии XML для определения логической структуры документов использовался набор формальных правил, называемый DTD — декларацией типа документа (document type declaration). Помимо этого, в начале мая 2001 года была принята новая техническая рекомендация языка под названием XML-схема (XML Schema), которая также формально задает логическую структуру документа, определяет используемые типы данных, количество повторений и многое другое.

В этой главе мы разберем основы логического построения ХМL-документов с использованием DTD.

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

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

□ ELEMENT — определение элемента;

□ ATTLIST — определение списка атрибутов элемента;

□ ENTITY — определение сущности;

□ NOTATION — определение нотации.

Эти определения могут быть заданы с использованием конструкции DOCTYPE непосредственно в документе:

и т.д.

]>

Другой возможностью определения декларации документа является использование внешнего файла:

В этом случае можно также дополнять внешние определения внутренними:

и т.д.

]>

Декларация типа документа определяется следующей EBNF-продукцией:

[28] doctypedecl ::= '

                     ('[' (markupdecl | DeclSep)* ']' S?)? '>'

Имя, соответствующее продукции Name, которая идет следом за ключевым словом DOCTYPE, определяет имя корневого элемента ХМL-документа. В предыдущем примере в корне документа должен стоять элемент advert.

Выражение (S ExternalID) ? указывает на то, что декларация типа документа может указываться во внешнем источнике (например, в файле), который описывается внешним идентификатором ExternalID.

[75] ExternalID ::= 'SYSTEM' S SystemLiteral

                    | 'PUBLIC' S PubidLiteral S SystemLiteral

В случае системного идентификатора ("SYSTEM"), SystemLiteral определяет URI определения типа документа. В случае публичного идентификатора, к этому параметру добавляется PubidLiteral, сообщающий дополнительную информацию о ресурсе. Обрабатывающее программное обеспечение может включать в себя DTD для заданного публичного идентификатора. Например, документы, написанные на языке XHTML, должны начинаться следующим объявлением:

 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">

Программа, обрабатывающая документ с таким заголовком, сможет по публичному идентификатору понять, что документ создан на языке XHTML, а значит, обрабатывать его нужно в соответствии со стандартом этого языка. Если же обрабатывающая программа не в курсе определений XHTML, она сможет загрузить декларацию типа по адресу http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd. Публичные идентификаторы, как правило, используются в языках, получающих широкое распространение, поскольку в этом случае формат логической структуры будет известен и без загрузки DTD.

Выражение ('[' (markupdecl | DeclSep) * ']' S?) ? в продукции doctypedecl означает, что в декларации типа документа в квадратных скобках может содержаться последовательность нетерминалов markupdecl и DeclSep.

Первый из этих нетерминалов, markupdecl, показывает, определения какого вида содержатся в DTD:

[29] markupdecl ::= elementdecl

                    | AttlistDecl

                    | EntityDecl

                    | NotationDecl

                    | PI

                    | Comment

С правилами PI и Comment мы уже знакомы — в данной продукции они показывают, что в DTD также можно использовать инструкции по обработке и комментарии.

Нетерминалы elementdecl, AttlistDecl, EntityDecl и NotationDecl соответствуют определениям элемента, списка атрибутов, сущности и нотации. Они будут подробно разобраны в следующих четырех разделах.

Нетерминал DeclSep соответствует разделителю объявлений, которые перечисляются в DTD. Этот разделитель может быть либо пробельным пространством, либо параметризованной сущностью:

[28а] DeclSep ::= PEReference | S

В случае, если определения в DTD разделяются сущностью-параметром, ее содержимое интерпретируется как обычные определения вида markupdecl.

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

Определение элемента задает имя и тип содержимого элемента в следующем виде:

Имя элемента должно начинаться с буквы, подчеркивания ("_") или двоеточия (":") и содержать буквы, цифры, некоторые знаки пунктуации (такие, как "_" — подчеркивание, ":" — двоеточие, "." — точка, "-" — тире или знак минуса) и модифицирующие символы (см. разд. "Базовые продукции ХМL" данной главы).

Примером имени элемента может быть "A", "B:12", "MyEasyName", "doc.xml".

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

□ EMPTY, в случае, когда элемент обязан быть пустым;

□ ANY, в случае, когда элемент может содержать что угодно;

□ формальное правило, определяющее элементы, и данные, которые может содержать элемент, а также порядок их следования.

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

Декларация

]>

определяет документ с корневым элементом advert, в котором могут встречаться также элементы product и classified, причем элементы advert и product могут содержать любые данные и любые из объявленных элементов, а элемент classified всегда должен быть пустым.

Приведем пример документа, построенного в соответствии с этой декларацией.

Листинг 1.3. Документ с декларацией типа

]>

  Покупайте наших слонов!

В третьем случае содержимое элемента определяется при помощи формальных правил, которые очень похожи на те, которые используются в расширенных формах Бэкуса-Наура. Подобно тому, как в EBNF формальные правила используются для того, чтобы стандартизировать последовательность символов, составляющую конструкции некоторого языка, в определениях элементов они используются для описания содержимого элемента — последовательности из символьных данных и дочерних элементов.

Количество, с которым элемент может появляться в этой последовательности, формально записывается с использованием символов-модификаторов "*", "?", "+", которые имеют следующие значения:

□ а? — означает, что элемент а может быть пропущен в последовательности;

□ а — означает, что элемент а должен присутствовать в последовательности на этом месте ровно один раз;

□ а* — задает последовательность из нуля или более элементов а;

□ a+ — задает последовательность из одного или более элементов а.

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

Элементы перечисляются через запятую в круглых скобках, например (a, b, c) — это последовательность, состоящая из элементов a, b, c. Такая запись означает, что первым должен идти элемент a, затем сразу же за ним элемент b и элемент c.

Выбор элемента задается аналогично перечислению, только разделительным символом является не запятая, а знак '|'. Например, (a | b | c) задает выбор одного из трех элементов a, b или c.

При записи выбора и перечисления элементы могут также указываться с использованием модификаторов количества.

Пример

(a* | b? | с | d+)

определяет содержимое, как последовательность, состоящую из нуля или более элементов a или одного элемента b, который может быть пропущен, или ровно одного элемента с, или последовательностью, состоящей из одного или более элементов d.

Помимо этого, формальные правила могут использовать при записи другие формальные правила.

Пример

((a | b), (с | d))

задает содержимое, первым элементом которого является a или b, вторым — элемент с или d.

Содержимое элементов может также включать символьные данные, которые обозначаются при помощи ключевого слова #PCDATA (parsable character data — разбираемые символьные данные).

Пример

означает, что элемент product должен содержать только символьные данные.

Помимо текста элементы могут также включать в себя другие элементы. Содержимое такого типа называется смешанным. Формальные правила смешанного содержимого должны всегда иметь вид (#PCDATA | ... | ... ) *.

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

Пример

Предположим, мы хотим определить документ со следующей логической структурой:

□ корневым элементом документа является элемент advert;

□ элемент advert содержит последовательность, состоящую из нескольких элементов product и одного элемента classified, который может быть пропущен;

□ элемент product может содержать текст и другие элементы product в любом порядке;

□ элемент classified не имеет содержимого.

Документ соответствующей логической структуры может быть задан следующим образом.

Листинг 1.4

]>

  Покупайте наших слонов!

Определению элемента соответствует EBNF-продукция elementdecl:

[45] elementdecl ::= ''

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

[46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | children

Строка "EMPTY" соответствует пустому элементу, "ANY" — любому содержимому, нетерминал Mixed — смешанному содержимому, children — содержимому, которое определяется формальными правилами.

[47] children ::= (choice | seq) ('?' | '*' | '+')?

[48] cp       ::= (Name | choice | seq) ('?' | '*' | '+')?

[49] choice   ::= '(' S? cp ( S? '|' S? cp )+ S? ')'

[50] seq      ::= '(' S? cp ( S? ',' S? cp )* S? ')'

[51] Mixed    ::= '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'

                  | '(' S? '#PCDATA' S? ')'

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

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

 атрибут1 тип1 значение1

 атрибут2 тип2 значение2

 и т. д ...>

В этом определении элемент задает имя элемента, для которого определяется данный список атрибутов, атрибут — имя атрибута, тип — тип атрибута и значение — значение атрибута.

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

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

□ CDATA — символьные данные;

□ ID — уникальный идентификатор;

□ IDREF — ссылка на уникальный идентификатор;

□ IDREFS — набор ссылок;

□ ENTITY — сущность;

□ ENTITIES — набор сущностей;

□ NMTOKEN — именной токен;

□ NMTOKENS — набор именных токенов;

□ NOTATION — нотация;

□ перечисление возможных значений атрибута.

Следует поподробнее остановиться на типе ID, поскольку атрибуты этого типа играют важную роль в повышении эффективности обработки XML-документов. Атрибуты типа ID могут содержать значения, которые однозначным образом идентифицируют элемент в документе. То есть, если тип атрибута объявлен как ID, его значение должно быть уникальным внутри документа. Это позволяет создавать для элементов с ID-атрибутами индексы по значению атрибута, для более быстрого доступа. Например, в языке XPath, имеется функция id, которая по данному строковому параметру возвращает множество, состоящее из элемента, ID-атрибут которого совпадает с этим параметром. Естественно, тип ID не гарантирует, что доступ к элементам в любом случае будет производиться быстрее — это зависит от реализации обрабатывающих программ. Однако большинство современных XML-процессоров при работе с ID-атрибутами используют механизмы оптимизации.

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

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

□ ключевое слово #REQUIRED, которое показывает, что этот атрибут должен всегда присутствовать в элементе и иметь некоторое значение;

□ ключевое слово #IMPLIED, которое показывает, что атрибут является необязательным и может отсутствовать в элементе;

□ ключевое слово #FIXED, за которым следует значение, заключенное в кавычки — это задает атрибут, который всегда должен иметь одно и то же фиксированное значение;

□ значение, заключенное в кавычки, определяет значение атрибута по умолчанию.

Примеры

Декларация

 title CDATA #REQUIRED

 id ID #IMPLIED

 quantity CDATA "1"

 value CDATA #FIXED "дорого"

 color (серый|белый) "серый">

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

□ обязательный атрибут title, содержащий символьные данные;

□ необязательный атрибут id, который может содержать уникальный идентификатор элемента внутри документа;

□ атрибут quantity, который может и не присутствовать в документе — в этом случае его значение будет равно 1;

□ атрибут value, который всегда должен иметь значение "дорого";

□ атрибут color, который может иметь одно из значений — "серый" или "белый", по умолчанию "серый".

Разберем синтаксис определения списка атрибутов более детально. Этому определению соответствует следующее правило:

[52] AttlistDecl ::= ''

В этом правиле Name задает имя элемента, a AttDef* — набор определяемых атрибутов. Каждый атрибут задается правилом AttDef:

[53] AttDef ::= S Name S AttType S DefaultDecl

Здесь Name — имя, AttType — тип, a DefaultDecl — значение атрибута по умолчанию.

[54] AttType ::= StringType | TokenizedType | EnumeratedType

В соответствии со спецификацией, значения атрибутов бывают трех видов — строки (StringType), токены (TokenizedType) и тип перечисления (EnumeratedType).

[55] StringType    ::= 'CDATA'

[56] TokenizedType ::= 'ID' | 'IDREF' | 'IDREFS' | 'ENTITY'

                       | 'ENTITIES' | 'NMTOKEN' | 'NMTOKENS'

Тип перечисления (EnumeratedType) может задаваться нотациями (NotationType) и собственно перечислениями (Enumeration):

[57] EnumeratedType ::= NotationType | Enumeration

[58] NotationType   ::= 'NOTATION' S

                        '(' S? Name (S? '|' S? Name)* S? ')'

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

[59] Enumeration ::= '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')'

Значение атрибута описывается продукцией DefaultDecl следующим образом:

[60] DefaultDecl ::= '#REQUIRED' | '#IMPLIED'

                     | (('#FIXED' S)? AttValue)

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

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

Существует два способа определения сущности — внутреннее и внешнее.

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

Внутреннее определение сущности имеет вид:

Ссылка на сущность записывается как & имя ; (амперсант, затем имя сущности, затем точка с запятой).

Пример

В документе

]>

  Продается настоящий &animal;!

сущность animal имеет значение "слон". Ссылка на сущность используется дважды — в атрибуте title и в тексте элемента product. Этот документ эквивалентен документу

  Продается настоящий слон!

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

]>

  Продается настоящий &animal;!

Спецификация XML определяет несколько встроенных сущностей, которые перечислены в табл 1.1.

Таблица 1.1. Встроенные сущности XML

Встроенные сущности могут быть использованы для замены некоторых символов там, где они могут быть восприняты, как разметка. В частности, символы < (знак "меньше") и & (амперсант) вообще не могут появляться в тексте документа иначе, кроме как в виде сущностей.

Пример

  Продается серый слон весом > 5 тонн!

  Компания "слон & Слон".

На самом же деле в элементе product заключен текст

Продается серый слон весом > 5 тонн!

Компания "Слон & Слон".

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

Символьная сущность (или, как ее еще называют, символьная ссылка) записывается в виде &# код ; или &#x код; , где код — десятеричный и шестнадцатеричный Unicode-код символа в первом и втором случае соответственно.

Пример

Фраза "Миру-мир!" может быть записана с использованием символьных сущностей следующим образом:

&#х41С;&#х438;&#х440;&#х443; - мир!

Первое слово, "Миру" записано с использованием шестнадцатеричных unicode-кодов кириллицы, второе слово, "мир", записано с использованием десятичных кодов.

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

Определение внешней сущности имеет следующий синтаксис:

В этом определении имя точно так же, как и во внутренней сущности определяет имя сущности, в то время как URI определяет абсолютное или относительное местоположение файла.

Пример

Предположим, что мы создали файл animal.ent со следующим содержанием:

огромное серое животное

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

где ent/animal есть относительный путь до файла animal.ent. Если бы мы расположили файл на сервере, скажем, www.animalhost.com, сущность могла бы быть объявлена как

В документе ссылаться на объявленную внешнюю сущность мы будем точно так же, как ссылались бы на внутреннюю сущность:

]>

  Продается &animal; весом > 5 тонн!

  Рождественские скидки!

В этом случае элемент product будет иметь текст

Продается огромное серое животное весом > 5 тонн!

Рождественские скидки!

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

Такой способ определения внешней сущности имеет следующий синтаксис:

Например, сущность animal мы можем переопределить как

 "http://www.animalhost.com/animal.ent">

Специальный процессор зоологических XML-файлов, встретив публичный идентификатор -//ZOO//Elephant//Description поймет, что речь идет о слоне, и не станет загружать файл animal.ent с удаленного сервера, вставив собственное описание слона.

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

□ замена часто повторяющихся частей документа;

□ разбивка одного XML-документа на отдельные модули;

□ замена некоторых символов, которые иначе были бы восприняты, как разметка;

□ использование символов с соответствующими кодами Unicode.

Синтаксис использования сущностей в тексте документа довольно прост. Символьная сущность определяется продукцией CharRef следующим образом:

[66] CharRef ::= '&#' [0-9]+ ';' | "&#x' [0-9a-fA-F]+ ';'

CharRef — это либо десятичная, либо шестнадцатеричная символьная сущность. В первом случае вместо имени сущности стоит набор, цифр от 0 до 9, во втором — к этому набору добавляются буквы a, b, c, d, e, f в любом регистре символов. Ведущие нули не имеют никакого значения, &#х0020; точно так же, как и &#х20; соответствует пробельному символу.

Обычной сущности, объявленной внутри или вне документа, соответствует продукция EntityRef:

[68] EntityRef ::= '&' Name

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

[67] Reference ::= EntityRef | CharRef

Здесь следует сделать небольшое отступление и сказать о том, что конструкции вида & имя ; или &#x код ; , о которых мы говорили как о сущностях, на самом деле являются не сущностями, а ссылками на сущности. &#x код ; — это ссылка на символьную, а & имя ; — на обычную сущность. Сама сущность — это именованный объект, к которому обрабатывающая программа должна обращаться при обработке ссылки с соответствующим именем. Однако, поскольку связь между сущностью и ссылкой на нее однозначна (одно не существует без другого), сами ссылки очень часто называют сущностями. Название продукции Reference переводится с английского как "ссылка", но пониматься в данном контексте может, в том числе, и как сущность.

Определение обычной сущности соответствует следующей продукции:

[71] GEDecl ::= ''

Name, как обычно, определяет имя, a EntityDef, соответственно, значение сущности. Это значение может быть задано как внутри документа (первый вариант выбора, EntityValue), так и вне его (второй вариант, ExternalID NDataDecl?).

[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)

EntityValue — это всего лишь символьное значение, взятое в кавычки.

Второй вариант синтаксиса EntityDef соответствует определению внешней сущности, то есть сущности, определение которой не содержится в самом документе.

Внешние сущности могут быть двух типов:

□ разбираемые внешние сущности (англ. parsed entity) — данные, которые воспринимаются и обрабатываются как XML;

□ неразбираемые внешние сущности (англ. unparsed entity) — данные не-XML типа (например, изображения или бинарные файлы, которые необходимо использовать в данном документе).

Неразбираемые сущности определяются наличием нетерминала NDataDecl в определении.

[76] NdataDecl ::= S 'NDATA' S Name

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

Синтаксически сущности-параметры очень похожи на обычные сущности. При объявлении и использовании сущности-параметра ее имени должен предшествовать символ '%'. Отличием сущностей-параметров является то, что они определяются и используются только внутри DTD.

Пример

В качестве примера объявим параметризованную сущность coords, которую впоследствии будем использовать в определениях элементов:

Используя объявленную сущность-параметр, элемент sphere, состоящий из элементов x, y, z (координаты сферы) и R (радиус), можно определить следующим образом:

Такое определение равносильно определению , но при этом оно является гораздо более гибким — если в новой версии создаваемого XML-языка вдруг произойдет смена регистра имен элементов x, y и z на X, Y и Z, декларацию типа документа изменять не придется.

Сущности-параметры широко используются в спецификациях Консорциума W3. Язык XSLT тоже имеет свою декларацию типа документа, но ее невозможно будет понять, не понимая механизма сущностей-параметров.

Синтаксис использования сущности-параметра (вернее, ссылки на нее) соответствует продукции PEReference, которая практически совпадает с продукцией EntityRef:

[69] PEReference ::= '%' Name ';'

Определение сущности-параметра также очень схоже с определением обычной сущности:

[72] PEDecl ::= ''

[74] PEDef  ::= EntityValue | ExternalID

Продукция EntityDecl, соответствующая определению сущности, как обычной, так и сущности-параметра, имеет следующий вид:

[70] EntityDecl ::= GEDecl | PEDecl

Напомним, что GEDecl соответствует объявлению обычной, a PEDecl — параметризованной сущности.

Определение нотации

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

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

Пример

Предположим, что мы используем графические изображения в формате GIF, для просмотра которых используется приложение gif-viewer.exe. Определение нотации будет иметь следующий вид:

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

Информация о вспомогательном приложении-обработчике (англ. helper application) указывается при определении нотации системным или публичным идентификатором. В отличие от определения внешней сущности, публичный идентификатор в нотации может указываться без системного идентификатора. Фактически, нотация имеет три варианта определения:

Если информация о вспомогательном приложении несущественна, можно воспользоваться определением следующего вида:

Существует два основных способа применения нотаций. Первый — объявление неразбираемых сущностей и использование их имен в атрибутах типа ENTITY или ENTITIES, второй — указание имени нотации в атрибуте типа NOTATION для того, чтобы задать формат данных, который содержит данный элемент.

Первый способ можно продемонстрировать простым документом, который задает меню (листинг 1.5).

Листинг 1.5. Использование неразбираемых сущностей в атрибутах элементов

  image ENTITY #REQUIRED

  title CDATA #REQUIRED

  href CDATA #REQUIRED>

]>

Проанализируем декларацию типа этого документа.

□ Декларация типа говорит о том, что корневым элементом этого документа является элемент menu.

□ В соответствии с определением этот элемент состоит из нескольких субэлементов menuitem.

□ В соответствии с определением элемент menuitem должен быть пустым.

□ Запись определяет в элементе menuitem следующие атрибуты:

 • обязательный атрибут image, в котором должно указываться имя сущности;

 • обязательный атрибут title, содержащий символьные данные;

 • обязательный атрибут href, содержащий символьные данные.

□ Запись определяет нотацию с именем gif и закрепляет за ней приложение gif-viewer.exe.

□ Запись определяет нотацию с именем jpg и закрепляет за ней приложение jpg-viewer.exe.

□ Запись определяет внешнюю неразбираемую сущность с именем news, которая имеет формат (нотацию) gif.

□ Запись определяет внешнюю неразбираемую сущность с именем products, которая имеет нотацию jpg.

□ Запись определяет внешнюю неразбираемую сущность с именем support, которая имеет нотацию gif.

Посмотрим теперь, какую информацию нам дают такие громоздкие определения. Обратимся к записи одного из элементов menuitem:

С атрибутами title и href все ясно: они содержат простые символьные данные. Атрибут image несколько сложнее, он предоставляет гораздо больше информации. Типом этого атрибута является ENTITY, значит текст, который он содержит, является не просто символьными данными: он задает имя сущности, связанной с данным атрибутом. Иначе говоря, с атрибутом image связывается сущность.

Анализируя определение сущности products, обрабатывающая программа может понять, что это — неразбираемая внешняя сущность формата jpg, которая хранится в файле prod.jpg и для обработки которой можно использовать приложение jpg-viewer.exe.

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

Пример

Листинг 1.6. Использование нотаций для определения формата содержимого элемента

  type NOTATION (rtf|htm|txt) #REQUIRED>

 <[NOTATION rtf SYSTEM "winword.exe">

]>

    ...

    ...

  ]]>

В этом документе определяется три нотации, три формата данных: rtf, htm и txt. Атрибут type элемента root указывает формат данных, которые содержатся в этом элементе — в данном случае это "htm" (что, очевидно, соответствует HTML-документу).

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

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

Проблема многих языков заключается в том, что для них существует несколько альтернативных кодировок символов. Например, для кириллицы существуют такие кодировки, как CP-866, KOI8-R, CP-1251, ISO-8859-5, кодовая страница Macintosh и другие, но вместе с тем не существует единого стандарта, принятого де-факто. В итоге, для того, чтобы быть уверенным, что документ будет прочтен, его нужно представлять в трех или четырех кодировках, что очень неудобно.

Для того чтобы решить эти и некоторые другие проблемы, был создан стандарт Unicode. Unicode присваивает уникальный код любому символу, независимо от платформы, независимо от программы, независимо от языка. Символам кириллицы Unicode присваивает коды в диапазоне от #x400 до #x4ff. Таблица кодов для кириллицы может быть найдена в формате PDF на Web-сайте Unicode:

http://www.unicode.org/charts/PDF/U0400.pdf.

Использование Unicode

Для описания символов сотен языков всего мира, а также других символьных обозначений (например, математических символов) Unicode позволяет использовать три формы кодирования — UTF-8, UTF-16 и UTF-32.

UTF-8

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

□ Символы с кодами в интервале #x0–#x7F кодируются одним байтом, первый бит которого равен нулю.

□ Для остальных символов число байт определяется количеством ведущих единиц первого байта последовательности.

□ Два первые бита каждого последующего байта равны единице и нулю соответственно.

□ Все остальные биты используются для кодирования символа.

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

Таблица 1.2 . Формы кодирования символов в UTF-8

К примеру, символу "Э" (заглавной русской букве "Э") Unicode присваивает код #x42D или 10000101101 в двоичном представлении. Это значение входит в интервал #x80-#x7ff, значит, для кодирования нужно использовать двух-байтовую форму вида 110xxxxx 10xxxxxx, где символы "x" обозначают 11 бит, доступных для кодировки. Таким образом, данному символу будет соответствовать следующий двоичный код:

110 10000  10 101101

или #xD0AD в шестнадцатеричном представлении.

Полужирным шрифтом выделены управляющие биты UTF-8 (110 означает, что символ закодирован двухбайтной последовательностью, 10 определяет второй байт последовательности), курсивом — биты кода символа.

Удобство UTF-8 заключается в том, что кодировка первых 127 символов совпадает с широко распространенной 7-битной кодировкой ASCII. Это делает возможным использование уже существующего программного обеспечения для обработки текста в UTF-8, например текстовых редакторов.

UTF-16

Для записи наиболее часто используемых символов с кодами, меньшими #xFFFF, UTF-16 использует двухбайтные последовательности, в которых каждый бит соответствует биту кода. Помимо этого, в UTF-16 могут быть также представлены символы с кодами в диапазоне #10000-#FFFFF. Для кодирования этих символов в UTF-16 применяются пары 16-битных значений в интервале #xD800-#xDFFF (ранее зарезервированные Unicode), называемые суррогатными парами (surrogate pairs). Младшие 10 бит каждого значения отводятся на кодировку символа, что в итоге дает 20 бит, достаточных для записи любого кода, не превышающего #xFFFFF (табл. 1.3).

Таблица 1.3 . Формы кодирования символов в UTF-16

Примеры

Символ "Э" с кодом #x42D будет записан в UTF-16 в виде последовательности из двух байт — #x042D.

Для символа с кодом #x153DC (в двоичном представлении — 10101001111011100) понадобится 4 байта. Он будет записан в виде

110110 0001010100  110110 1111011100

или #xD854DBDC в шестнадцатеричном исчислении.

Полужирным шрифтом выделены управляющие биты UTF-16, курсивом — биты кода символа.

UTF-32

UTF-32 является самой простой формой кодирования — для каждого символа, вне зависимости от диапазона, используются 4 байта. Такой способ, несомненно, не является самым экономичным с точки зрения объема хранимой информации, но во многих случаях предоставляет определенные преимущества при обработке текста, так как символы не нужно декодировать.

Коды некоторых символов Unicode

В таблицах символов Unicode кодируются не только символы и знаки различных языков, но также и некоторые управляющие символы, например, неразрываемый пробел (no-break space), табуляция, перенос строки и так далее. Коды некоторых из этих символов, часто использующихся в XML-технологиях, мы приводим в табл. 1.4.

Таблица 1.4 . Unicode-коды некоторых символов

Коды многих других символов можно найти на Web-сайте Unicode Consortium в разделе Code Charts: http://www.unicode.org/charts/.

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

Создание новых языков

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

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

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

Главным недостатком XML является громоздкость синтаксиса. Например, арифметическое выражение 2*2 может быть выражено в XML приблизительно как:

 2

 2

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

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

□ WML (Wireless Markup Language) — язык разметки для беспроводных устройств, основной формат данных для беспроводного протокола WAP;

□ SVG (Scalable Vector Graphics) — язык описания масштабируемой векторной графики;

□ XHTML — XML-совместимая версия языка гипертекстовой разметки документов;

□ SOAP (Simple Object Access Protocol) — XML-протокол для обмена информацией в распределенных системах;

□ RDF (Resource Description Framework) — система описания ресурсов;

□ XML/EDI (XML/Electronic Data Interchange) — XML-язык для представления сообщений EDI в системах В2В и электронной коммерции;

□ OML (Ontology Markup Language) — язык для описания онтологий и тезаурусов;

□ VoxML (Voice Markup Language) — язык разметки для голосовых приложений;

□ MathML (Mathematical Markup Language) — язык для описания математических выражений;

□ CML (Chemical Markup Language) — язык для описания химических формул;

□ UML exchange Format — XML-выражения языка UML (Unified Modeling Language);

□ CDF (Channel Description Format) — язык для описания данных для автоматической доставки клиенту (технология push-каналов).

Несмотря на то, что XML это язык разметки, он вполне подходит для создания языков программирования. Самым лучшим примером является язык XSLT, которому посвящена эта книга. Кроме того, существует множество менее известных языков, например XML-версия функционального языка Lisp, язык HaXML и другие.

Хранение данных

Практические всегда, когда приложение должно хранить данные во внешних файлах, неизбежны два процесса: парсинг (синтаксический разбор) при считывании данных и сериализация (создание физического выражения состояния объектов) при сохранении (рис. 1.2).

Рис. 1.2. Стандартная схема хранения данных

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

Рис. 1.3. Схема хранения данных в формате XML

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

□ хранимые в XML данные могут иметь практически любую сложность; она ограничена лишь концептуальной сложностью древовидных структур;

□ хранимые в XML данные можно снабжать метаинформацией (например, комментариями или инструкциями по обработке);

□ XML как формат пригоден даже для хранения двоичных данных, если они будут преобразованы в подходящую текстовую кодировку;

□ SAX и DOM/XPath-интерфейсы обеспечивают эффективный доступ к XML-данным.

Противопоказаний к использованию XML в качестве формата хранения данных очень мало. Во-первых, разработчик может посчитать нерациональным включение объемных XML-библиотек в приложение размером в 10 Кбайт. Во-вторых, XML-формат это не самый компактный способ хранения данных. В-третьих, открытость внешним приложениям также может быть лишней.

Обмен данными и проекты интеграции

Большое количество систем, стандартов и технологий, о которых мы говорили ранее, приводит к тому, что эффективно связать разные источники данных в одну систему не получается. Даже такие, казалось бы, однородные источники, как системы управления базами данных, применяют языки запросов и форматы представления выбираемой информации, которые редко полностью совместимы между собой. Как следствие, проекты интеграции в таких условиях требуют больших усилий — требуется вникать в детали различных баз данных, протоколов, операционных систем и так далее.

В результате интеграция нескольких приложений или систем реализуется по схеме, показанной на рис. 1.4.

Рис. 1.4. Типичная схема интеграции нескольких приложений

Несложно оценить трудозатраты подобного рода проекта. Заставить разные системы работать вместе — чрезвычайно трудоемкая задача.

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

Такое решение сразу же намного упрощает проект — ведь вместо реализации взаимодействия между каждой парой систем следует всего лишь научить каждую из них "говорить" на созданном XML-языке. Иначе говоря, все сводится к разработке нескольких врапперов (англ. wrapper — упаковщик, программное средство создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы), которые будут переводить со стандартного XML-языка интегрированной системы на язык, понятный каждой системе в отдельности.

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

□ XML-языки не зависят от аппаратных и программных платформ, что позволяет связывать разнородные системы;

□ выразительная мощность XML достаточно велика для того, чтобы описать данные практически любой сложности;

□ средства разработки и стандартные библиотеки для XML существуют практически на всех платформах и для большинства популярных языков программирования;

□ методы работы с XML достаточно стандартны для того, чтобы в разных системах можно было пользоваться одинаковыми приемами;

□ информация, оформленная в виде XML, может обрабатываться не только машинами, но и человеком (что намного облегчает отладку).

Рис. 1.5. Интеграция на основе XML