Технология XSLT — Алексей Валиков — страница 4 читать онлайн бесплатно

Несомненным достоинством XML является также и то, что это чрезвычайно простой язык. Основных конструкций в XML очень мало, но, несмотря на это, с их помощью можно создавать разметку документов практически любой сложности.
Для того чтобы познакомиться с устройством XML-документов, рассмотрим простой пример:
  Покупайте наших слонов!
Первая строка документа определяет его как XML-документ, построенный в соответствии с первой версией языка. Следующая строка содержит открывающий тег 
. Далее находится открывающий тег 
, который имеет атрибут title
 со значением "Слон"
. Четвертая строка в документе — рекламный лозунг "Покупайте наших слонов!"
. Затем следует закрывающий тег 
 и, наконец, закрывающий тег 
.
XML использует ту же теговую разметку, что и HTML, но при этом теги в XML не просто ограничивают часть текста документа — они выделяют в документе один элемент. В предыдущем примере документ имел два элемента — 
advert
:
  Покупайте наших слонов!
и 
product
:
 Покупайте наших слонов!
Как видно, элемент 
product
 включен в элемент advert
. Точно так же, как в HTML одни теги могли находиться внутри других тегов, в XML элементы могут содержать другие элементы, а также иметь атрибуты и содержать текст. В следующем разделе мы подробно рассмотрим основные конструкции XML, которые понадобятся нам в дальнейшем.
Конструкции XML
Помимо элементов, атрибутов и текста, документы могут также содержать другие конструкции, такие как комментарии, инструкции по обработке и секции символьных данных. Эти базовые составляющие используются для того, чтобы гибко, но в четком соответствии со стандартом, размечать документы любой сложности. Далее мы подробно разберем каждую из основных конструкций 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. Например, вместо 
 в XML следует писать 
.
Замечание
Для того чтобы привести синтаксис HTML в соответствие со стандартом XML, был создан язык XHTML. Этот язык полностью соответствует синтаксису XML, что делает возможным обработку XHTML-документов XML-средствами, но при этом набор тегов XHTML идентичен набору тегов языка HTML. К сожалению, далеко не все браузеры поддерживают XHTML. Чаще всего проблемы возникают именно с пустыми элементами (или одиночными тегами в терминах HTML): например, браузеры могут некорректно воспринимать запись вида 

. В большинстве случаев проблема решается использованием перед косой чертой пробела: запись вида 
, скорее всего, будет обработана корректно.
Атрибут
В элементах можно использовать атрибуты с присвоенными им значениями. Атрибут задается в следующем виде:
атрибут="значение"
Например, в записи гипертекстовой ссылки
<а 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). Она имеет вид:
версия" encoding="кодировка" standalone="yes | no"/>
Несмотря на то, что 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 не следует забывать один из основополагающих принципов — нужно не просто выражать информацию, нужно выражать ее стандартным образом. Это включает в себя не только синтаксические принципы разметки текста, изложенные выше, но и ограничения, накладываемые на логическую структуру документов. Изобретая свой собственный набор элементов и атрибутов, мы вместе с этим набором изобретаем логический формат, а именно то, каким образом элементы и атрибуты должны формировать документ, какая информация должна присутствовать обязательно, а какая является опциональной, какие данные должны содержать те или иные атрибуты и элементы.
В первой версии 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
Имя сущности Значение Описание
lt < знак "меньше"
gt > знак "больше"
amp & амперсант
apos ' апостроф или одинарные кавычки
quot " двойные кавычки
Встроенные сущности могут быть использованы для замены некоторых символов там, где они могут быть восприняты, как разметка. В частности, символы 
<
 (знак "меньше") и &
 (амперсант) вообще не могут появляться в тексте документа иначе, кроме как в виде сущностей.
Пример
  Продается серый слон весом > 5 тонн!
  Компания "слон & Слон".
На самом же деле в элементе 
product
 заключен текст
Продается серый слон весом > 5 тонн!
Компания "Слон & Слон".
Довольно часто бывает необходимо использовать в документе символы набора Unicode, обращаясь к ним по десятичным или шестнадцатеричным кодам. В таких случаях можно использовать символьные сущности.
Символьная сущность (или, как ее еще называют, символьная ссылка) записывается в виде 
&#код;
 или &#xкод;
, где код
 — десятеричный и шестнадцатеричный Unicode-код символа в первом и втором случае соответственно.
Пример
Фраза "
Миру-мир!
" может быть записана с использованием символьных сущностей следующим образом:
&#х41С;&#х438;&#х440;&#х443; - мир!
Первое слово, "
Миру
" записано с использованием шестнадцатеричных unicode-кодов кириллицы, второе слово, "мир
", записано с использованием десятичных кодов.
Внешние сущности содержатся во внешних файлах. Если ссылка на внешнюю сущность появляется в документе, то на ее место копируется содержимое внешнего файла.
Определение внешней сущности имеет следующий синтаксис:
имя SYSTEM "URI">
В этом определении 
имя
 точно так же, как и во внутренней сущности определяет имя сущности, в то время как URI
 определяет абсолютное или относительное местоположение файла.
Пример
Предположим, что мы создали файл 
animal.ent
 со следующим содержанием:
огромное серое животное
Для того чтобы использовать содержимое этого файла в документе, мы должны объявить внешнюю сущность следующим образом:
где 
ent/animal
 есть относительный путь до файла animal.ent
. Если бы мы расположили файл на сервере, скажем, www.animalhost.com
, сущность могла бы быть объявлена как
В документе ссылаться на объявленную внешнюю сущность мы будем точно так же, как ссылались бы на внутреннюю сущность:
]>
  Продается &animal; весом > 5 тонн!
  Рождественские скидки!
В этом случае элемент 
product
 будет иметь текст
Продается огромное серое животное весом > 5 тонн!
Рождественские скидки!
Внешняя сущность может быть также объявлена при помощи так называемого публичного идентификатора. В этом случае, при объявлении указывается не только местоположение сущности, но еще и идентификатор, который предоставляет программному обеспечению, обрабатывающему документ, некоторую дополнительную информацию. Например, в некоторых случаях XML-процессор может уже включать в себя определение внешней сущности, и ему не нужно будет получать содержимое файла, находящегося на удаленном сервере.
Такой способ определения внешней сущности имеет следующий синтаксис:
имя PUBLIC "идентификатор" "URL">
Например, сущность 
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) указывается при определении нотации системным или публичным идентификатором. В отличие от определения внешней сущности, публичный идентификатор в нотации может указываться без системного идентификатора. Фактически, нотация имеет три варианта определения:
имя SYSTEM "системный ид-р">
имя PUBLIC "публичный ид-р" "системный ид-р">
имя PUBLIC "публичный ид-р">
Если информация о вспомогательном приложении несущественна, можно воспользоваться определением следующего вида:
имя SYSTEM "">
Существует два основных способа применения нотаций. Первый — объявление неразбираемых сущностей и использование их имен в атрибутах типа 
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-документу).
Несмотря на то, что нотации являются довольно мощным механизмом, ввиду очевидной сложности, широкого распространения их использование не получило. Почти того же самого эффекта можно добиться более простыми способами, например, используя в элементах дополнительные атрибуты.
Символьные данные в XML-документах
Каковы бы ни были структура и синтаксис текстового документа, основой его всегда являются символы. Для хранения и обработки текста на компьютерах, которые по своей природе являются цифровыми устройствами, каждому символу нужно поставить в соответствие числовой код.
Проблема многих языков заключается в том, что для них существует несколько альтернативных кодировок символов. Например, для кириллицы существуют такие кодировки, как 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
Диапазон Кол-во байт Форма кодирования Кол-во бит
#x0-#x7F 1 0xxxxxxx 7
#x80-#x7FF 2 110xxxxx 10xxxxxx 11
#x800-#xFFFF 3 1110xxxx 10xxxxxx 10xxxxxx 16
#x10000- #x1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 21
К примеру, символу "
Э
" (заглавной русской букве "Э
") Unicode присваивает код #x42D
 или 10000101101
 в двоичном представлении. Это значение входит в интервал #x80-#x7ff
, значит, для кодирования нужно использовать двух-байтовую форму вида 110xxxxx 10xxxxxx
, где символы "x
" обозначают 11 бит, доступных для кодировки. Таким образом, данному символу будет соответствовать следующий двоичный код:
11010000 10101101
или 
#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
Диапазон Кол-во байт Форма кодирования Кол-во бит
#x0-#xD7FF 2 xxxxxxxx xxxxxxxx 16
#xD800-#xDFFF Зарезервированы
#xE000-#xFFFF 2 xxxxxxxx xxxxxxxx 16
#x10000-#xFFFFF 4 110110xxxxxxxxxx 110110xxxxxxxxxx 20
Примеры
Символ "
Э
" с кодом #x42D
 будет записан в UTF-16 в виде последовательности из двух байт — #x042D
.
Для символа с кодом 
#x153DC
 (в двоичном представлении — 10101001111011100
) понадобится 4 байта. Он будет записан в виде
1101100001010100 1101101111011100
или 
#xD854DBDC
 в шестнадцатеричном исчислении.
Полужирным шрифтом выделены управляющие биты UTF-16, курсивом — биты кода символа.
UTF-32
UTF-32 является самой простой формой кодирования — для каждого символа, вне зависимости от диапазона, используются 4 байта. Такой способ, несомненно, не является самым экономичным с точки зрения объема хранимой информации, но во многих случаях предоставляет определенные преимущества при обработке текста, так как символы не нужно декодировать.
Коды некоторых символов Unicode
В таблицах символов Unicode кодируются не только символы и знаки различных языков, но также и некоторые управляющие символы, например, неразрываемый пробел (no-break space), табуляция, перенос строки и так далее. Коды некоторых из этих символов, часто использующихся в XML-технологиях, мы приводим в табл. 1.4.

Таблица 1.4. Unicode-коды некоторых символов
Код Обозначение Описание
#х9 [НТ] Горизонтальная табуляция (horizontal tabulation)
#xA [LF] Перевод строки (line feed)
#xD [CR] Возврат каретки (carriage return)
#x20 [SP] Пробел (space)
#x21 ! Восклицательный знак (exclamation sign)
#x22 " Двойные кавычки (quotation mark)
#x26 & Амперсант (ampersand)
#x27 ' Апостроф или одинарные кавычки (apostrophe)
#x3C < Знак "меньше" или левая угловая скобка (less-than sign)
#x3F ? Вопросительный знак (question mark)
#xA0 [NBSP] Неразрываемый пробел (no-break space)
Коды многих других символов можно найти на Web-сайте Unicode Consortium в разделе Code Charts: http://www.unicode.org/charts/.
Базовые продукции XML
Теперь, когда мы разобрали модель символов Unicode, которая используется в XML, можно дать EBNF-определения основных базовых конструкций языка — символов, имен, именных токенов и их последовательностей.
В XML можно использовать любые символы Unicode, кроме суррогатных блоков и символов с кодами 
#xFFFE
 и #xFFFF
:
[2] Char ::= #x9 | #xA | #xD | [#x20 - #xD7FF]
             | [#хЕ000 - #xFFFD) | [#х10000 - #x10FFFF]
Для удобства все множество символов разделено на несколько категорий.
□ Буквы, которые соответствуют продукции 
Letter
, в свою очередь, делятся на основные (BaseChar
) и идеографические (Ideographic
). Буквы относятся к алфавитам, из которых состоят слова различных языков. Продукции букв чрезвычайно просты, но громоздки, поскольку перечисляют символы различных алфавитов. Читатель может легко найти их в технической рекомендации XML по адресу http://www.w3.org/TR/REC-xml.html под номерами [84] (Letter
), [85] (BaseChar
) и [86] (Ideographic
).
□ Цифры, которые составляют в различных культурах числа. Цифры определяются продукцией 
Digit
 с номером [88].
□ Модифицирующие символы (
CombiningChar
), которые изменяют написание или звучание символов, как, например, #x308 — двойная точка сверху символа, которая используется для обозначения умляута в немецком и для замены e
 на ё
 в русском языке. Продукция CombiningChar
 имеет номер [87].
□ Символы расширения (
Extender
). Продукция Extender
 имеет порядковый номер [89].
Следующей простейшей символьной конструкцией является пробельное пространство 
S
. Приведем еще раз его продукцию:
[3] S ::= (#х9 | #хА | #xD | #x20)+
Во многих продукциях XML-языков используются имена. Например, имена даются элементам, атрибутам, переменным XPath и так далее. В основе определения имени лежат именные символы 
NameChar
:
[4] NameChar ::= Letter | Digit | CombiningChar | Extender
                 | '.' | '-' | '_' | ':'
Имя начинается либо буквой, либо символами "
_
" или ":
" и состоит из последовательности именных символов:
[5] Name ::= (Letter | '_' | ' :') (NameChar*)
В некоторых правилах XML используется последовательность имен, соответствующая продукции 
Names
:
[6] Names ::= Name (S Name)*
Кроме того, техническая рекомендация определяет так называемый именной токен 
NmToken
 — строку, которая может состоять из одного или более именных символов и последовательности таких токенов, NmTokens
.
[7] NmToken  ::= (NameChar)+
[8] NmTokens ::= NmToken (S NmToken)*
Символьные данные могут заключаться в кавычки для того, чтобы формировать литералы. В XML определены следующие литералы: значение сущности (
EntityValue
), значение атрибута (AttValue
), системный литерал (SystemLiteral
), а также PubidLiteral
 — литерал, определяющий публичный идентификатор ресурса (см. раздел "Определение сущности" данной главы):
[9] EntityValue    ::= '"' ([^%&"] | PEReference | Reference)* '"'
                       | "'" ([^%&'] | PEReference | Reference)* "'"
[10] AttValue      ::= '"' ([^<&"] | Reference)* '"'
                       | ([^<&"] | Reference)* "'"
[11] SystemLiteral ::= ('"' [^"]* '"')
                       | ("'" [^']* "'")
[12] PubidLiteral  ::= '"' PubidChar* '"'
                       | "'" (PubidChar - "'")*
[13] PubidChar     ::= #x20 | #xD | #xA
                       | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]
В литералах 
EntityValue
 и AttValue
 допустимо использовать продукции сущностей (PEReference
, Reference
). Это означает, что при определении значений сущностей и атрибутов можно использовать ссылки на сущности, например, в элементе заданном как:
атрибут 
title
 имеет значение крейсер"Аврора"
. Двойные кавычки были определены посредством встроенных сущностей.
Символьные данные, которые задаются продукцией 
CharData
, могут состоять из любых символов, кроме символов "<
" и "&
", которые используются в XML в качестве управляющих. CharData
 главным образом используется в секциях CDATA
, и, соответственно, не может содержать терминирующую последовательность "]]>
".
[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)
XML-документы с точки зрения спецификации
Теперь, когда мы разобрали практически все структурные единицы XML, осталось определить стандартным образом синтаксис для самих XML-документов. Им соответствует продукция 
document
:
[1] document ::= prolog element Misc
Итак, XML-документ состоит из пролога, единственного корневого элемента и дополнительного нетерминала 
Misc
, который может включать инструкции по обработке, комментарии и пробельные символы:
[27] Misc ::= Comment | PI | S
Остановимся отдельно на прологе XML-документа. Пролог состоит из необязательной декларации XML (
XMLDecl
), необязательной декларации типа документа (doctypedecl
), инструкций, комментариев и пробельных символов:
[22] prolog ::= XMLDeci? Misc* (doctypedecl Misc*)?
В зависимости от того, насколько строго документы соответствуют спецификации XML и собственным DTD-объявлениям, они могут быть хорошо оформленными (well-formed) и правильными (valid).
Хорошо оформленный документ соответствует всем синтаксическим правилам XML и некоторым дополнительным ограничениям, например:
□ имя открывающего тега элемента должно совпадать с именем его закрывающего тега;
□ имена атрибутов элемента не должны повторяться;
□ в значении атрибута нельзя использовать символ "
<
". Этот символ должен обязательным образом заменяться на сущность;
□ сущности должны быть определены до использования;
□ сущности-параметры могут быть использованы только в блоках DTD;
□ документ должен иметь единственный корневой элемент, содержащий все остальные элементы и символьные данные этого документа. Вне корневого документа допускаются только комментарии, инструкции по обработке, декларация XML и блок DTD.
Правильные документы должны быть хорошо оформленными, и при этом их логическая структура должна удовлетворять объявлениям, которые содержатся в декларации типа документа (DTD).
Для того чтобы документ мог быть обработан различными приложениями стандартным образом, он должен как минимум быть хорошо оформленным. Выполнение этого требования означает, что документ корректен с точки зрения синтаксиса, и для его логического представления можно использовать любую из стандартных моделей. Например, если в элементе документа приведены два атрибута с одинаковыми именами, возможно, с точки зрения автора, это логично и корректно, однако, стандартными средствами такой документ обработать не удастся.
Требование правильности означает четкое соответствие выбранной логической схеме документа. Объявления декларации типа документа накладывают на логическую структуру документа определенные ограничения с тем, чтобы он мог быть стандартным образом обработан не только синтаксическими, но и семантическими процессорами, то есть программами, которые не только могут распознать синтаксис XML-документа, но и "понять" его смысл, переданный разметкой.
Использование технологии XML

Имя сущности	Значение	Описание
`lt`	`<`	знак "меньше"
`gt`	`>`	знак "больше"
`amp`	`&`	амперсант
`apos`	`'`	апостроф или одинарные кавычки
`quot`	`"`	двойные кавычки

Диапазон	Кол-во байт	Форма кодирования	Кол-во бит
`#x0-#x7F`	1	0xxxxxxx	7
`#x80-#x7FF`	2	110xxxxx 10xxxxxx	11
`#x800-#xFFFF`	3	1110xxxx 10xxxxxx 10xxxxxx	16
`#x10000- #x1FFFFF`	4	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx	21

Диапазон	Кол-во байт	Форма кодирования	Кол-во бит
`#x0-#xD7FF`	2	`xxxxxxxx xxxxxxxx`	16
`#xD800-#xDFFF`	Зарезервированы
`#xE000-#xFFFF`	2	`xxxxxxxx xxxxxxxx`	16
`#x10000-#xFFFFF`	4	`110110xxxxxxxxxx 110110xxxxxxxxxx`	20

Код	Обозначение	Описание
`#х9`	`[НТ]`	Горизонтальная табуляция (horizontal tabulation)
`#xA`	`[LF]`	Перевод строки (line feed)
`#xD`	`[CR]`	Возврат каретки (carriage return)
`#x20`	`[SP]`	Пробел (space)
`#x21`	`!`	Восклицательный знак (exclamation sign)
`#x22`	`"`	Двойные кавычки (quotation mark)
`#x26`	`&`	Амперсант (ampersand)
`#x27`	`'`	Апостроф или одинарные кавычки (apostrophe)
`#x3C`	`<`	Знак "меньше" или левая угловая скобка (less-than sign)
`#x3F`	`?`	Вопросительный знак (question mark)
`#xA0`	`[NBSP]`	Неразрываемый пробел (no-break space)



    
        
            Предыдущая
        
        Стр. 4 из 66
        
            Следующая

Конструкции XML

Элемент

Атрибут

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

Секции СDATA

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

Пространства имён

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

Структура XML-документа

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

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

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

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

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

Символьные данные в XML-документах

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

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

Базовые продукции XML

XML-документы с точки зрения спецификации

Использование технологии XML

Оглавление