Глава 1 Введение в XML
Что такое XML?
За последние несколько десятков лет, прошедших с создания первых электронных устройств, в игру с природой человеком была введена третья сторона — вычислительные машины. Человек постепенно доверил им свою память, переложил на них сложные алгоритмические задачи, вычисления, принятие решений, и вообще все то, с чем плохо справлялся сам в информационном мире.
Но на всем пути становления информационных систем человек неизбежно сталкивался с одной и той же проблемой — с проблемой понимания. Если два человека, говорящие на разных языках, попробуют объяснить что- нибудь друг другу, то это легко может получиться, когда проблема проста, например, "как пройти к большому зданию с куполом наверху?". Однако же, в случае, если объяснить нужно что-нибудь более сложное, то, не зная языка собеседника, сделать это будет очень трудно.
Проблема понимания между человеком и машиной усугубляется еще и тем, что машина — это цифровое устройство, и все данные в ней состоят из атомов информации — битов, принимающих только два значения — "0" (что иногда понимается, как "нет" или "ложь") и "1" ("да", "истина"). Изначально цифровые устройства вообще использовались только для решения математических задач — расчета баллистики, шифрации и тому подобного.
Для машинной записи естественных языков люди ставили в соответствие символам числа, организуя, таким образом, текстовую информацию в машинном представлении. Это был первый шаг на пути взаимопонимания между машинами и человеком — отпала необходимость писать программы в двоичных кодах. В течение короткого времени было создано множество языков программирования, одновременно понятных как человеку, поскольку они использовали синтаксические конструкции естественных языков, так и машине, потому как могли быть переведены (транслированы) в машинные коды.
Затем произошел взрыв. Программирование, которое во времена машинных кодов было уделом энтузиастов, стало массовым, идеи и вложения полились рекой, и дальнейшее развитие информационных технологий можно сравнить с распространением ударной волны.
В жизни современного общества сложно переоценить эффект, произведенный появлением и повсеместным распространением нового глобального пространства обмена информации — сетью Интернет. То, что начиналось как военная разработка для доставки электронных сообщений и депеш, вылилось в новое информационное измерение пространства, не знающее географических границ. Интернет позволил обмениваться информацией в электронном виде, объемы которой к тому времени уже были огромны.
Однако, Интернет, в свою очередь, возродил старую проблему понимания — вопрос "как ты поймешь то, что я тебе скажу?" был заменен проблемой "как система В сможет переработать информацию, которую предоставит ей система A?". Пытаясь ответить на это, люди стали создавать стандарты и протоколы, которые позволили бы системам общаться на одних языках. Вместе с тем, по мере глобализации Интернета и увеличения числа систем, обменивающихся информацией (от рабочих станций обычных пользователей — до суперсерверов с огромными базами данных), объем информации, требовавшей стандартного выражения, прогрессировал экспоненциально.
Расширяемый язык разметки XML (extensible Mark-up Language) — это результат довольно успешной попытки создать язык для текстового выражения структурированной информации в стандартном виде. XML — это метаязык в том смысле, что сам по себе он не имеет операторов, не определяет никакую алгоритмическую последовательность действий и не выполняет никаких вычислений, его цель — описывать новые языки документов.
Разметка документов
Идею разметки документов будет проще всего проиллюстрировать на примере. Представим себе следующий рекламный текст:
Предлагаем Вашему вниманию новый 3-х камерный холодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, 3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12-15. Фирма "Горск-Холод".
Размещая это объявление где-нибудь на Web-сайте, нам может понадобиться выделить некоторые части, чтобы получить представление вида:
Предлагаем Вашему вниманию новый 3-х камерный холодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, 3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12-15.
Фирма "Горск-Холод".
Идея разметки состоит в том, чтобы использовать для выделения частей документа простые текстовые метки, называемые тегами. Теги разграничивают документ, выделяя в нем части и присваивая им некоторые особенности (например, указывая на то, что часть текста надо подчеркнуть).
Простым примером языка разметки является уже, скорее всего, знакомый читателю HTML — язык разметки гипертекста. В HTML задан набор тегов для визуального форматирования документа, например:
□
содержимое
— выделяет содержимое, как параграф;
□
— задает перенос строки;
□
содержимое
— выделяет содержимое полужирным шрифтом;
□
содержимое
— выделяет содержимое курсивом;
□
содержимое
— подчеркивает содержимое.
Теги могут быть парными и одиночными. Парные теги (например,
содержимое
) выделяют часть документа, одиночные (например,
) задают некую инструкцию.
В предыдущем примере текст может быть размечен следующим образом.
Листинг 1.1. HTML-разметка рекламного объявления
<Р>Предлагаем Вашему вниманию новый 3-х камерный холодильник <В>"Горск" объемом 250 л. и стоимостью всего <В>4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, <В>3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12- 15.
Фирма "Горск-Холод".
Теперь этот документ несет в себе не только данные о коммерческом предложении, но и примитивную информацию о том, как он должен выглядеть визуально. Это делает документ более понятным, но понятным для человека, а не для машины. Словосочетания "быстрое охлаждение" и "бесплатная доставка по городу", выделенные в тексте одинаковыми тегами, на самом деле описывают совершенно разные вещи. Первое — свойство продукта, второе — сервис, предоставляемый фирмой. Иначе говоря, одни и те же теги в этом документе имеют разный смысл — один и тот же синтаксис выражает разную семантику.
Для решения этой проблемы несоответствия, XML предлагает очень простой и весьма эффективный способ — расширить множество используемых тегов так, чтобы они могли полностью выразить всю семантику, которой только может обладать документ. Например.
Листинг 1.2 XML-разметка рекламного объявления
Предлагаем Вашему вниманию новый 3 -x камерный
холодильник "Горск"
объемом 250 л. и стоимостью всего 4500
рублей!
Новый дизайн, быстрое охлаждение и
низкое энергопотребление ,
3-x годовая гарантия на все узлы и агрегаты, а
также бесплатная доставка по городу !
Заказывайте прямо сейчас по телефону 0-91-12-15 .
Фирма "Горск-Холод".
В таком виде этот документ содержит гораздо более подробную информацию о своей структуре: внутри тега
указано наименование продукта, внутри тега
— цена, внутри тега
— какой сервис предоставляет фирма и так далее. Такой текст уже можно обработать программно. Если понадобится составить таблицу, содержащую названия холодильников, объем, цену, название фирмы и телефон, все, что потребуется сделать — это получить содержимое тегов
,
,
,
и
. При этом совершенно не теряется возможность визуального представления документа: нужно лишь определить, как будет выглядеть содержимое того или иного тега.
Таким образом, просто расширив множество тегов, мы убили сразу двух зайцев.
□ Явным образом выделили в документе структуру данных. Это делает возможной дальнейшую машинную обработку документа, который при этом все еще остается понятным человеку.
□ Отделили данные, содержащиеся в документе, от того, каким образом документ будет представлен визуально. Это дает широкие возможности для публикации документов на различных носителях — на бумаге, в Интернет, на мобильных устройствах.
В этих двух положениях и есть смысл XML (англ. extensible Mark-up Language, расширяемый язык разметки) — отделять данные от представления и создавать в текстовом виде документы со структурой, указанной явным образом.
Синтаксически в XML, по сравнению с HTML, нет ничего нового. Это такой же текст, размеченный тегами, но с той лишь разницей, что в HTML существует ограниченный набор тегов, которые можно использовать в документах, в то время как XML позволяет создавать и использовать любую разметку, которая только может понадобиться для подробного описания данных.
За последние несколько десятков лет, прошедших с создания первых электронных устройств, в игру с природой человеком была введена третья сторона — вычислительные машины. Человек постепенно доверил им свою память, переложил на них сложные алгоритмические задачи, вычисления, принятие решений, и вообще все то, с чем плохо справлялся сам в информационном мире.
Но на всем пути становления информационных систем человек неизбежно сталкивался с одной и той же проблемой — с проблемой понимания. Если два человека, говорящие на разных языках, попробуют объяснить что- нибудь друг другу, то это легко может получиться, когда проблема проста, например, "как пройти к большому зданию с куполом наверху?". Однако же, в случае, если объяснить нужно что-нибудь более сложное, то, не зная языка собеседника, сделать это будет очень трудно.
Проблема понимания между человеком и машиной усугубляется еще и тем, что машина — это цифровое устройство, и все данные в ней состоят из атомов информации — битов, принимающих только два значения — "0" (что иногда понимается, как "нет" или "ложь") и "1" ("да", "истина"). Изначально цифровые устройства вообще использовались только для решения математических задач — расчета баллистики, шифрации и тому подобного.
Для машинной записи естественных языков люди ставили в соответствие символам числа, организуя, таким образом, текстовую информацию в машинном представлении. Это был первый шаг на пути взаимопонимания между машинами и человеком — отпала необходимость писать программы в двоичных кодах. В течение короткого времени было создано множество языков программирования, одновременно понятных как человеку, поскольку они использовали синтаксические конструкции естественных языков, так и машине, потому как могли быть переведены (транслированы) в машинные коды.
Затем произошел взрыв. Программирование, которое во времена машинных кодов было уделом энтузиастов, стало массовым, идеи и вложения полились рекой, и дальнейшее развитие информационных технологий можно сравнить с распространением ударной волны.
В жизни современного общества сложно переоценить эффект, произведенный появлением и повсеместным распространением нового глобального пространства обмена информации — сетью Интернет. То, что начиналось как военная разработка для доставки электронных сообщений и депеш, вылилось в новое информационное измерение пространства, не знающее географических границ. Интернет позволил обмениваться информацией в электронном виде, объемы которой к тому времени уже были огромны.
Однако, Интернет, в свою очередь, возродил старую проблему понимания — вопрос "как ты поймешь то, что я тебе скажу?" был заменен проблемой "как система В сможет переработать информацию, которую предоставит ей система A?". Пытаясь ответить на это, люди стали создавать стандарты и протоколы, которые позволили бы системам общаться на одних языках. Вместе с тем, по мере глобализации Интернета и увеличения числа систем, обменивающихся информацией (от рабочих станций обычных пользователей — до суперсерверов с огромными базами данных), объем информации, требовавшей стандартного выражения, прогрессировал экспоненциально.
Расширяемый язык разметки XML (extensible Mark-up Language) — это результат довольно успешной попытки создать язык для текстового выражения структурированной информации в стандартном виде. XML — это метаязык в том смысле, что сам по себе он не имеет операторов, не определяет никакую алгоритмическую последовательность действий и не выполняет никаких вычислений, его цель — описывать новые языки документов.
Разметка документов
Идею разметки документов будет проще всего проиллюстрировать на примере. Представим себе следующий рекламный текст:
Предлагаем Вашему вниманию новый 3-х камерный холодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, 3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12-15. Фирма "Горск-Холод".Размещая это объявление где-нибудь на Web-сайте, нам может понадобиться выделить некоторые части, чтобы получить представление вида:
Предлагаем Вашему вниманию новый 3-х камерный холодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, 3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12-15.Фирма "Горск-Холод".Идея разметки состоит в том, чтобы использовать для выделения частей документа простые текстовые метки, называемые тегами. Теги разграничивают документ, выделяя в нем части и присваивая им некоторые особенности (например, указывая на то, что часть текста надо подчеркнуть).
Простым примером языка разметки является уже, скорее всего, знакомый читателю HTML — язык разметки гипертекста. В HTML задан набор тегов для визуального форматирования документа, например:
□
содержимое
□
□
содержимое□
содержимое□
содержимоеТеги могут быть парными и одиночными. Парные теги (например,
содержимое
В предыдущем примере текст может быть размечен следующим образом.
<Р>Предлагаем Вашему вниманию новый 3-х камерный холодильник <В>"Горск" объемом 250 л. и стоимостью всего <В>4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление, <В>3-х годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу! Заказывайте прямо сейчас по телефону 091-12- 15.
Фирма "Горск-Холод".Теперь этот документ несет в себе не только данные о коммерческом предложении, но и примитивную информацию о том, как он должен выглядеть визуально. Это делает документ более понятным, но понятным для человека, а не для машины. Словосочетания "быстрое охлаждение" и "бесплатная доставка по городу", выделенные в тексте одинаковыми тегами, на самом деле описывают совершенно разные вещи. Первое — свойство продукта, второе — сервис, предоставляемый фирмой. Иначе говоря, одни и те же теги в этом документе имеют разный смысл — один и тот же синтаксис выражает разную семантику.
Для решения этой проблемы несоответствия, XML предлагает очень простой и весьма эффективный способ — расширить множество используемых тегов так, чтобы они могли полностью выразить всю семантику, которой только может обладать документ. Например.
Предлагаем Вашему вниманию новый 3 -x камерный холодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей! Новый дизайн, быстрое охлаждение и низкое энергопотребление , 3-x годовая гарантия на все узлы и агрегаты, а также бесплатная доставка по городу ! Заказывайте прямо сейчас по телефону 0-91-12-15 . Фирма "Горск-Холод". В таком виде этот документ содержит гораздо более подробную информацию о своей структуре: внутри тега
Таким образом, просто расширив множество тегов, мы убили сразу двух зайцев.
□ Явным образом выделили в документе структуру данных. Это делает возможной дальнейшую машинную обработку документа, который при этом все еще остается понятным человеку.
□ Отделили данные, содержащиеся в документе, от того, каким образом документ будет представлен визуально. Это дает широкие возможности для публикации документов на различных носителях — на бумаге, в Интернет, на мобильных устройствах.
В этих двух положениях и есть смысл XML (англ. extensible Mark-up Language, расширяемый язык разметки) — отделять данные от представления и создавать в текстовом виде документы со структурой, указанной явным образом.
Синтаксически в XML, по сравнению с HTML, нет ничего нового. Это такой же текст, размеченный тегами, но с той лишь разницей, что в HTML существует ограниченный набор тегов, которые можно использовать в документах, в то время как XML позволяет создавать и использовать любую разметку, которая только может понадобиться для подробного описания данных.
XML снаружи и изнутри
Несомненным достоинством 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 является также и то, что это чрезвычайно простой язык. Основных конструкций в XML очень мало, но, несмотря на это, с их помощью можно создавать разметку документов практически любой сложности.
Для того чтобы познакомиться с устройством XML-документов, рассмотрим простой пример:
Покупайте наших слонов! Первая строка документа определяет его как XML-документ, построенный в соответствии с первой версией языка. Следующая строка содержит открывающий тег
title"Слон""Покупайте наших слонов!"XML использует ту же теговую разметку, что и HTML, но при этом теги в XML не просто ограничивают часть текста документа — они выделяют в документе один элемент. В предыдущем примере документ имел два элемента —
advert Покупайте наших слонов! и
product Покупайте наших слонов!Как видно, элемент
productadvertКонструкции XML
Помимо элементов, атрибутов и текста, документы могут также содержать другие конструкции, такие как комментарии, инструкции по обработке и секции символьных данных. Эти базовые составляющие используются для того, чтобы гибко, но в четком соответствии со стандартом, размечать документы любой сложности. Далее мы подробно разберем каждую из основных конструкций XML-документа.
Элемент
Теги в XML-документе не просто размечают текст — они выделяют объект, который и называется элементом. Элементы являются основными структурными единицами XML — именно они иерархически организуют информацию, содержащуюся в документе.
Элементы могут быть пустыми, то есть не содержать ни данных, ни других конструкций, либо непустыми — включать в себя текст, другие элементы и т.п.
Пустой элемент имеет следующий вид:
<имя атрибут1="значение1" атрибут2="значение2" и т.д./>
Непустые элементы имеют вид:
<имя атрибут1="значение1" атрибут2="значение2" и т.д.> ... содержимое элемента... имя> sometext И в том, и в другом случае, имя задает имя элемента, а конструкции вида
атрибутX="значениеХ"MyElementmyelementMYELEMENTЭлементы являются основной конструкцией языка XML. Организуя содержимое в элементах, можно явно выделить иерархическую структуру документа. Легко заметить, что документ, состоящий из вложенных друг в друга элементов, устроен подобно дереву: родительский элемент является корнем, в то время как дочерние элементы, которые включаются в него, являются ветками, а если они не содержат ничего более, то и листьями. Следующий пример (рис. 1.1) иллюстрирует эту концепцию.
Рис. 1.1. Документ и соответствующее ему дерево элементов
Очень важно понять, что XML-документ логически организован в виде дерева. Дерево является довольно простой структурой для обработки, но при этом выразительная сложность его весьма велика. Древовидная структура является одной из наиболее подходящих абстракций для описания объектов и отношений в реальном мире — возможно именно древовидное устройство наряду с простотой использования обеспечили XML такой потрясающий успех.
Обратимся теперь к синтаксису элементов. EBNF-правило, определяющее элемент, выглядит следующим образом:
[39] element ::= EmptyElemTag | STag content ETagПустому элементу соответствует нетерминал
EmptyElemTagSTagcontentETagОткрывающий тег состоит из имени (
NameAttribute[40] STag ::= '<' Name (S Attribute)* S? '>'В ряде случаев атрибуты тега могут отсутствовать.
Перед закрывающей угловой скобкой тега могут также стоять пробельные символы, поэтому вполне корректной будет следующая запись:
<а href="http://www.xsltdev.ru">В закрывающем теге имени предшествует косая черта ("
/[42] ETag ::= ''Имена в открывающем и закрывающем тегах должны совпадать.
Содержимое элемента может состоять из элементов (нетерминал
elementReferenceCDSectPICommentCharData[43] content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*Пустой элемент не имеет содержимого и задается продукцией
EmptyElemTag[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'Тег пустого элемента выглядит точно так же, как и тег непустого элемента с той лишь разницей, что перед закрывающей угловой скобкой стоит символ косой черты ("
/
Для того чтобы привести синтаксис 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)* "'"Значение атрибута записывается в одинарных или двойных кавычках, причем оно не может содержать символов '
<&<&ReferenceИнструкция по обработке
В XML-документы могут быть включены не относящиеся к содержимому документа инструкции, несущие информацию для приложения, которое будет этот документ обрабатывать. Инструкции по обработке имеют вид:
Инструкция по обработке всегда заключается в угловые скобки со знаками вопроса. Первая часть инструкции, приложение, определяет программу или систему, которой предназначена вторая часть, ее содержимое.
Примером инструкции по обработке может послужить следующая запись:
В данном случае целевое приложение имеет имя '
servПродукции инструкций по обработке имеют следующий вид:
[16] PI ::= ' (S (Char* - (Char* '?>' Char*)))? '?>'В этом правиле выражение
(S (Char* - (Char* '?>' Char*)))?'?>'Целевое приложение может иметь любое имя (кроме "
xmlPITarget[17] PITarget ::= Name - (('X' | 'х') ('М' | 'm') ('L' | 'l'))В XML определена особая конструкция, называемая ХМL-декларацией (XML declaration). Она имеет вид:
версия" encoding="кодировка" standalone="yes | no"/>Несмотря на то, что XML-декларация очень похожа на инструкцию по обработке, с точки зрения стандарта она таковой не является. Если же подходить менее строго, то смысл XML-декларации полностью соответствует смыслу инструкции по обработке: она сообщает обрабатывающему данный документ программному обеспечению информацию о некоторых свойствах этого документа. XML-декларация может содержать псевдоатрибуты
versionencodingstandaloneВ отличие от элементов, XML-декларация, как и инструкции по обработке не могут иметь атрибутов. Однако их содержимое очень часто образуется в форме
имя="значение"Псевдоатрибут
versionversion="1.0"Псевдоатрибут
encodingБольшинство документов, созданных на русском языке, используют кириллические кодировки
windows-1251KOI8-Rи
соответственно.
Для документов, в которых использовались только нижние 127 символов ASCII, то есть, символы с кодами, не превышающими
#x7FencodingПсевдоатрибут
standalonestandalone"yes"Декларации XML соответствует продукция
XMLDecl[23] XMLDecl ::= ' SDDecl? S? '?>'Продукция
VersionInfoversion[24] VersionInfo ::= S? 'version' Eq ("'" VersionNum "'" | "" VersionNum "")Значение версии документа может состоять из латинских букв и цифр, а также символов "
_.:-[26] VersionNum ::= ([a-zA-Z0-9_.:] | '-')+Кодировка объявляется продукцией
EncodingDeclVersionInfo[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-Псевдоатрибуту
standaloneSDDecl[32] SDDecl ::= S 'standalone' Eq (("'" ('yes' | 'no') "'") | ( '"' ('yes' | 'no') '"' ) )Расшифровывается это правило очень просто: псевдоатрибут
standaloneyesnoСекции СDATA
Секции CDATA выделяют части документа, внутри которых текст не должен восприниматься как разметка. CDATA означает буквально "character data" — символьные данные. Секции CDATA задаются следующим образом:
содержимое]]>Поскольку синтаксис разметки документов в XML имеет текстовую форму, часто бывает, что само содержимое документа может быть воспринято как разметка. В том случае, когда этого желательно избежать, самым простым выходом будет поместить такие данные внутрь секции CDATA.
Следующий текст в документе
Покупайте наших слонов! будет воспринят как разметка. Для того чтобы избежать этого, достаточно написать
Покупайте наших слонов!]]>Такая конструкция уже будет воспринята как символьные данные. Другим примером может быть использование символов "
<&Секции символьных данных задаются четырьмя довольно простыми правилами:
[18] CDSect ::= CDStart CData CDEnd[19] CDStart ::= '[20] CData ::= Char* - (Char* ']]>' Char*))[21] CDEnd ::= ']]>'Содержимое секции символьных данных, отвечающее продукции 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"> ...элементы
stylesheettemplateВ одном элементе можно определять несколько префиксов пространств имен. Как правило, при использовании множества префиксов, все они определяются в корневом элементе, а затем используются по всему документу.
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-документа элементов и атрибутов, принадлежащих различным логическим схемам документов. Более того, термин "пространство имен" часто используется как эквивалент логической схеме документа, например, когда говорят "элемент
templatetemplateСинтаксические правила, которые описывают определения пространств имен, задаются не в спецификации 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'Имя
NCNamePrefixedAttNameName[NS4] NCName ::= (Letter | '_') (NCNameChar)*[NS5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | ExtenderРасширенные имена
Использование пространств имен значительно изменяет понятие имени. Действительно, если
www:templatexsl:templatetemplateВследствие этого в спецификациях группы XML-языков вводится такое понятие, как расширенное имя, которое состоит из двух частей: локальной части и идентификатора пространства имен, которое соответствует префиксу имени.
Представим себе элемент вида
Расширенное имя этого элемента будет состоять из локальной, части
stylesheethttp://www.w3.org/1999/XSL/TransformРасширенные имена считаются совпадающими, если их локальные части равны и, при этом, они относятся к одному пространству имен.
Префикс в расширенном имени может быть опущен. В таком случае идентификатор пространства имен будет либо выбран по умолчанию (если имеется соответствующее объявление), либо будет нулевым.
Для описания имен элементов и атрибутов, которые должны иметь расширенное представление, используется продукция
QName[NS6] QName ::= (Prefix ':')? LocalPartНетерминалу
PrefixLocalPart[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?)? '>'Имя, соответствующее продукции
NameDOCTYPEadvertВыражение
(S ExternalID) ?ExternalID[75] ExternalID ::= 'SYSTEM' S SystemLiteral | 'PUBLIC' S PubidLiteral S SystemLiteralВ случае системного идентификатора (
"SYSTEM"SystemLiteralPubidLiteral "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?) ?doctypedeclmarkupdeclDeclSepПервый из этих нетерминалов,
markupdecl[29] markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | CommentС правилами
PICommentНетерминалы
elementdeclAttlistDeclEntityDeclNotationDeclНетерминал
DeclSep[28а] DeclSep ::= PEReference | SВ случае, если определения в DTD разделяются сущностью-параметром, ее содержимое интерпретируется как обычные определения вида
markupdeclОпределение элемента
Определение элемента задает имя и тип содержимого элемента в следующем виде:
Имя элемента должно начинаться с буквы, подчеркивания ("
_:_:.-Примером имени элемента может быть "
AB:12MyEasyNamedoc.xmlВ качестве содержимого элемента может быть указано:
□
EMPTY□
ANY□ формальное правило, определяющее элементы, и данные, которые может содержать элемент, а также порядок их следования.
Первые два случая определения элемента довольно просты. Их использование может быть продемонстрировано на следующем примере:
Декларация]>определяет документ с корневым элементом
advertproductclassifiedadvertproductclassifiedПриведем пример документа, построенного в соответствии с этой декларацией.
]> Покупайте наших слонов! В третьем случае содержимое элемента определяется при помощи формальных правил, которые очень похожи на те, которые используются в расширенных формах Бэкуса-Наура. Подобно тому, как в EBNF формальные правила используются для того, чтобы стандартизировать последовательность символов, составляющую конструкции некоторого языка, в определениях элементов они используются для описания содержимого элемента — последовательности из символьных данных и дочерних элементов.
Количество, с которым элемент может появляться в этой последовательности, формально записывается с использованием символов-модификаторов "
*?+□
а?а□
аа□
а*а□
a+аКроме того, содержимое может моделироваться как перечисление и выбор элементов.
Элементы перечисляются через запятую в круглых скобках, например
(a, b, c)abcabcВыбор элемента задается аналогично перечислению, только разделительным символом является не запятая, а знак '
|a | b | cabcПри записи выбора и перечисления элементы могут также указываться с использованием модификаторов количества.
(a* | b? | с | d+)определяет содержимое, как последовательность, состоящую из нуля или более элементов
abсdПомимо этого, формальные правила могут использовать при записи другие формальные правила.
((a | b), (с | d))задает содержимое, первым элементом которого является
abсdСодержимое элементов может также включать символьные данные, которые обозначаются при помощи ключевого слова
#PCDATAозначает, что элемент
productПомимо текста элементы могут также включать в себя другие элементы. Содержимое такого типа называется смешанным. Формальные правила смешанного содержимого должны всегда иметь вид
(#PCDATA | ... | ... ) *При помощи формальных правил можно точно и гибко задавать логическую структуру элементов документа. В качестве примера приведем определения элементов для нашего документа с рекламным объявлением.
Предположим, мы хотим определить документ со следующей логической структурой:
□ корневым элементом документа является элемент
advert□ элемент
advertclassified□ элемент
productproduct□ элемент
classifiedДокумент соответствующей логической структуры может быть задан следующим образом.
]> Покупайте наших слонов! Определению элемента соответствует EBNF-продукция
elementdecl[45] elementdecl ::= ''Нетерминал
contentspec[46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | childrenСтрока "
EMPTYANYMixedchildren[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 и т. д...>В этом определении
элементатрибуттипзначениеИмяТип□
CDATA□
ID□
IDREF□
IDREFS□
ENTITY□
ENTITIES□
NMTOKEN□
NMTOKENS□
NOTATION□ перечисление возможных значений атрибута.
Следует поподробнее остановиться на типе
IDIDIDIDidIDIDIDТип
IDIDIDREFIDREFSЗначениеЗначением□ ключевое слово
#REQUIRED□ ключевое слово
#IMPLIED□ ключевое слово
#FIXED□ значение, заключенное в кавычки, определяет значение атрибута по умолчанию.
Декларация
title CDATA #REQUIRED id ID #IMPLIED quantity CDATA "1" value CDATA #FIXED "дорого" color (серый|белый) "серый">определяет в элементе
product□ обязательный атрибут
title□ необязательный атрибут
id□ атрибут
quantity1□ атрибут
value"дорого"□ атрибут
color"серый""белый""серый"Разберем синтаксис определения списка атрибутов более детально. Этому определению соответствует следующее правило:
[52] AttlistDecl ::= ''В этом правиле
NameAttDef*AttDef[53] AttDef ::= S Name S AttType S DefaultDeclЗдесь
NameAttTypeDefaultDecl[54] AttType ::= StringType | TokenizedType | EnumeratedTypeВ соответствии со спецификацией, значения атрибутов бывают трех видов — строки (
StringTypeTokenizedTypeEnumeratedType[55] StringType ::= 'CDATA'[56] TokenizedType ::= 'ID' | 'IDREF' | 'IDREFS' | 'ENTITY' | 'ENTITIES' | 'NMTOKEN' | 'NMTOKENS'Тип перечисления (
EnumeratedTypeNotationTypeEnumeration[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"слон"titleproduct Продается настоящий слон! Если в будущем фирма переквалифицируется, и будет продавать, скажем, жирафов, можно будет, не изменяя всего документа, заменить только значение сущности:
]> Продается настоящий &animal;! Спецификация XML определяет несколько встроенных сущностей, которые перечислены в табл 1.1.
Таблица 1.1. Встроенные сущности XML
| Имя сущности | Значение | Описание |
|---|---|---|
|
|
знак "меньше" |
|
|
знак "больше" |
|
|
амперсант |
|
|
апостроф или одинарные кавычки |
|
|
двойные кавычки |
Встроенные сущности могут быть использованы для замены некоторых символов там, где они могут быть восприняты, как разметка. В частности, символы
<& Продается серый слон весом > 5 тонн! Компания "слон & Слон". На самом же деле в элементе
productПродается серый слон весом > 5 тонн!Компания "Слон & Слон".Довольно часто бывает необходимо использовать в документе символы набора Unicode, обращаясь к ним по десятичным или шестнадцатеричным кодам. В таких случаях можно использовать символьные сущности.
Символьная сущность (или, как ее еще называют, символьная ссылка) записывается в виде
&#код;&#xкод;кодФраза "
Миру-мир!&#х41С;&#х438;&#х440;&#х443; - мир!Первое слово, "
МирумирВнешние сущности содержатся во внешних файлах. Если ссылка на внешнюю сущность появляется в документе, то на ее место копируется содержимое внешнего файла.
Определение внешней сущности имеет следующий синтаксис:
имя SYSTEM "URI">В этом определении
имяURIПредположим, что мы создали файл
animal.entогромное серое животноеДля того чтобы использовать содержимое этого файла в документе, мы должны объявить внешнюю сущность следующим образом:
где
ent/animalanimal.entwww.animalhost.comВ документе ссылаться на объявленную внешнюю сущность мы будем точно так же, как ссылались бы на внутреннюю сущность:
]> Продается &animal; весом > 5 тонн! Рождественские скидки! В этом случае элемент
productПродается огромное серое животное весом > 5 тонн!Рождественские скидки!Внешняя сущность может быть также объявлена при помощи так называемого публичного идентификатора. В этом случае, при объявлении указывается не только местоположение сущности, но еще и идентификатор, который предоставляет программному обеспечению, обрабатывающему документ, некоторую дополнительную информацию. Например, в некоторых случаях XML-процессор может уже включать в себя определение внешней сущности, и ему не нужно будет получать содержимое файла, находящегося на удаленном сервере.
Такой способ определения внешней сущности имеет следующий синтаксис:
имя PUBLIC "идентификатор" "URL">Например, сущность
animal "http://www.animalhost.com/animal.ent">Специальный процессор зоологических XML-файлов, встретив публичный идентификатор
-//ZOO//Elephant//Descriptionanimal.entПодводя итог, можно выделить следующие случаи, когда следует использовать сущности:
□ замена часто повторяющихся частей документа;
□ разбивка одного XML-документа на отдельные модули;
□ замена некоторых символов, которые иначе были бы восприняты, как разметка;
□ использование символов с соответствующими кодами Unicode.
Синтаксис использования сущностей в тексте документа довольно прост. Символьная сущность определяется продукцией
CharRef[66] CharRef ::= '&#' [0-9]+ ';' | "&#x' [0-9a-fA-F]+ ';'CharRef09abcdef&#х0020;&#х20;Обычной сущности, объявленной внутри или вне документа, соответствует продукция
EntityRef[68] EntityRef ::= '&' NameСимвольная и обычная сущности объединяются в продукцию
Reference[67] Reference ::= EntityRef | CharRefЗдесь следует сделать небольшое отступление и сказать о том, что конструкции вида
&имя;&#xкод;&#xкод;&имя;ReferenceОпределение обычной сущности соответствует следующей продукции:
[71] GEDecl ::= ''NameEntityDefEntityValueExternalID NDataDecl?[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)EntityValueВторой вариант синтаксиса
EntityDefВнешние сущности могут быть двух типов:
□ разбираемые внешние сущности (англ. parsed entity) — данные, которые воспринимаются и обрабатываются как XML;
□ неразбираемые внешние сущности (англ. unparsed entity) — данные не-XML типа (например, изображения или бинарные файлы, которые необходимо использовать в данном документе).
Неразбираемые сущности определяются наличием нетерминала
NDataDecl[76] NdataDecl ::= S 'NDATA' S NameМы до сих пор не упомянули еще один важный случай сущности — параметризованные сущности или сущности-параметры. Сущности этого типа используются в DTD для более гибкого описания логической структуры документа.
Синтаксически сущности-параметры очень похожи на обычные сущности. При объявлении и использовании сущности-параметра ее имени должен предшествовать символ '
%В качестве примера объявим параметризованную сущность
coordsИспользуя объявленную сущность-параметр, элемент
spherexyzRТакое определение равносильно определению
xyzXYZСущности-параметры широко используются в спецификациях Консорциума W3. Язык XSLT тоже имеет свою декларацию типа документа, но ее невозможно будет понять, не понимая механизма сущностей-параметров.
Синтаксис использования сущности-параметра (вернее, ссылки на нее) соответствует продукции
PEReferenceEntityRef[69] PEReference ::= '%' Name ';'Определение сущности-параметра также очень схоже с определением обычной сущности:
[72] PEDecl ::= ''[74] PEDef ::= EntityValue | ExternalIDПродукция
EntityDecl[70] EntityDecl ::= GEDecl | PEDeclНапомним, что
GEDeclPEDeclОпределение нотации
С точки зрения физической модели, XML-документы являются не более чем текстом. Содержимое документов и их разметка имеет исключительно текстовый вид. Вместе с тем, во многих случаях документы должны включать данные других форматов, например, графические изображения или двоичные файлы. Несовместимость физической реализации XML и внешних данных такого типа не позволяет включать их в документ посредством обычных сущностей — для этих целей используются неразбираемые сущности и нотации.
Нотация — это ни что иное, как определение формата неразбираемой сущности. Нотация дает формату имя и предоставляет некоторую информацию о приложении, которое следует использовать для обработки этого формата.
Предположим, что мы используем графические изображения в формате
GIFgif-viewer.exeЭта запись определяет нотацию с именем
GIFИнформация о вспомогательном приложении-обработчике (англ. helper application) указывается при определении нотации системным или публичным идентификатором. В отличие от определения внешней сущности, публичный идентификатор в нотации может указываться без системного идентификатора. Фактически, нотация имеет три варианта определения:
имя SYSTEM "системный ид-р">имя PUBLIC "публичный ид-р" "системный ид-р">имя PUBLIC "публичный ид-р">Если информация о вспомогательном приложении несущественна, можно воспользоваться определением следующего вида:
имя SYSTEM "">Существует два основных способа применения нотаций. Первый — объявление неразбираемых сущностей и использование их имен в атрибутах типа
ENTITYENTITIESNOTATIONПервый способ можно продемонстрировать простым документом, который задает меню (листинг 1.5).
image ENTITY #REQUIRED title CDATA #REQUIRED href CDATA #REQUIRED> ]> Проанализируем декларацию типа этого документа.
□ Декларация типа
menu□ В соответствии с определением
menuitem□ В соответствии с определением
menuitem□ Запись
menuitem• обязательный атрибут
image• обязательный атрибут
title• обязательный атрибут
href□ Запись
gifgif-viewer.exe□ Запись
jpgjpg-viewer.exe□ Запись
newsgif□ Запись
productsjpg□ Запись
supportgifПосмотрим теперь, какую информацию нам дают такие громоздкие определения. Обратимся к записи одного из элементов
menuitemС атрибутами
titlehrefimageENTITYimageАнализируя определение сущности
productsjpgprod.jpgjpg-viewer.exeВторым способом использования нотаций является присвоение определенного формата содержимому элемента. Один (но не более чем один) из атрибутов элемента может иметь тип
NOTATION type NOTATION (rtf|htm|txt) #REQUIRED> <[NOTATION rtf SYSTEM "winword.exe"> ]> ... ... ]]>В этом документе определяется три нотации, три формата данных:
rtfhtmtxttyperoot"htm"Несмотря на то, что нотации являются довольно мощным механизмом, ввиду очевидной сложности, широкого распространения их использование не получило. Почти того же самого эффекта можно добиться более простыми способами, например, используя в элементах дополнительные атрибуты.
Символьные данные в XML-документах
Каковы бы ни были структура и синтаксис текстового документа, основой его всегда являются символы. Для хранения и обработки текста на компьютерах, которые по своей природе являются цифровыми устройствами, каждому символу нужно поставить в соответствие числовой код.
Проблема многих языков заключается в том, что для них существует несколько альтернативных кодировок символов. Например, для кириллицы существуют такие кодировки, как CP-866, KOI8-R, CP-1251, ISO-8859-5, кодовая страница Macintosh и другие, но вместе с тем не существует единого стандарта, принятого де-факто. В итоге, для того, чтобы быть уверенным, что документ будет прочтен, его нужно представлять в трех или четырех кодировках, что очень неудобно.
Для того чтобы решить эти и некоторые другие проблемы, был создан стандарт Unicode. Unicode присваивает уникальный код любому символу, независимо от платформы, независимо от программы, независимо от языка. Символам кириллицы Unicode присваивает коды в диапазоне от
#x400#x4ffhttp://www.unicode.org/charts/PDF/U0400.pdf.
Использование Unicode
Для описания символов сотен языков всего мира, а также других символьных обозначений (например, математических символов) Unicode позволяет использовать три формы кодирования — UTF-8, UTF-16 и UTF-32.
В UTF-8 символы разных диапазонов кодируются последовательностями, состоящими из разного количества байт в соответствии со следующими правилами.
□ Символы с кодами в интервале
#x0#x7F□ Для остальных символов число байт определяется количеством ведущих единиц первого байта последовательности.
□ Два первые бита каждого последующего байта равны единице и нулю соответственно.
□ Все остальные биты используются для кодирования символа.
В табл. 1.2 для каждого интервала символов показано количество байт, нужных для кодирования символа, форма кодирования и количество бит, доступных для кода.
Таблица 1.2. Формы кодирования символов в UTF-8
| Диапазон | Кол-во байт | Форма кодирования | Кол-во бит |
|---|---|---|---|
|
1 | 0xxxxxxx | 7 |
|
2 | 110xxxxx 10xxxxxx | 11 |
|
3 | 1110xxxx 10xxxxxx 10xxxxxx | 16 |
|
4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 21 |
К примеру, символу "
ЭЭ#x42D10000101101#x80-#x7ff110xxxxx 10xxxxxxx11010000 10101101или
#xD0ADПолужирным шрифтом выделены управляющие биты UTF-8 (
11010Удобство UTF-8 заключается в том, что кодировка первых 127 символов совпадает с широко распространенной 7-битной кодировкой ASCII. Это делает возможным использование уже существующего программного обеспечения для обработки текста в UTF-8, например текстовых редакторов.
Для записи наиболее часто используемых символов с кодами, меньшими
#xFFFF#10000-#FFFFF#xD800-#xDFFF#xFFFFFТаблица 1.3. Формы кодирования символов в UTF-16
| Диапазон | Кол-во байт | Форма кодирования | Кол-во бит |
|---|---|---|---|
|
2 | |
16 |
|
Зарезервированы | ||
|
2 | |
16 |
|
4 | |
20 |
Символ "
Э#x42D#x042DДля символа с кодом
#x153DC101010011110111001101100001010100 1101101111011100или
#xD854DBDCПолужирным шрифтом выделены управляющие биты UTF-16, курсивом — биты кода символа.
UTF-32 является самой простой формой кодирования — для каждого символа, вне зависимости от диапазона, используются 4 байта. Такой способ, несомненно, не является самым экономичным с точки зрения объема хранимой информации, но во многих случаях предоставляет определенные преимущества при обработке текста, так как символы не нужно декодировать.
Коды некоторых символов Unicode
В таблицах символов Unicode кодируются не только символы и знаки различных языков, но также и некоторые управляющие символы, например, неразрываемый пробел (no-break space), табуляция, перенос строки и так далее. Коды некоторых из этих символов, часто использующихся в XML-технологиях, мы приводим в табл. 1.4.
Таблица 1.4. Unicode-коды некоторых символов
| Код | Обозначение | Описание |
|---|---|---|
|
|
Горизонтальная табуляция (horizontal tabulation) |
|
|
Перевод строки (line feed) |
|
|
Возврат каретки (carriage return) |
|
|
Пробел (space) |
|
|
Восклицательный знак (exclamation sign) |
|
|
Двойные кавычки (quotation mark) |
|
|
Амперсант (ampersand) |
|
|
Апостроф или одинарные кавычки (apostrophe) |
|
|
Знак "меньше" или левая угловая скобка (less-than sign) |
|
|
Вопросительный знак (question mark) |
|
|
Неразрываемый пробел (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]Для удобства все множество символов разделено на несколько категорий.
□ Буквы, которые соответствуют продукции
LetterBaseCharIdeographicLetterBaseCharIdeographic□ Цифры, которые составляют в различных культурах числа. Цифры определяются продукцией
Digit□ Модифицирующие символы (
CombiningChareёCombiningChar□ Символы расширения (
ExtenderExtenderСледующей простейшей символьной конструкцией является пробельное пространство
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)*Кроме того, техническая рекомендация определяет так называемый именной токен
NmTokenNmTokens[7] NmToken ::= (NameChar)+[8] NmTokens ::= NmToken (S NmToken)*Символьные данные могут заключаться в кавычки для того, чтобы формировать литералы. В XML определены следующие литералы: значение сущности (
EntityValueAttValueSystemLiteralPubidLiteral[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] | [-'()+,./:=?;!*#@$_%]В литералах
EntityValueAttValuePEReferenceReferenceатрибут
title"Аврора"Символьные данные, которые задаются продукцией
CharData<&CharDataCDATA]]>[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)XML-документы с точки зрения спецификации
Теперь, когда мы разобрали практически все структурные единицы XML, осталось определить стандартным образом синтаксис для самих XML-документов. Им соответствует продукция
document[1] document ::= prolog element MiscИтак, XML-документ состоит из пролога, единственного корневого элемента и дополнительного нетерминала
Misc[27] Misc ::= Comment | PI | SОстановимся отдельно на прологе XML-документа. Пролог состоит из необязательной декларации XML (
XMLDecldoctypedecl[22] prolog ::= XMLDeci? Misc* (doctypedecl Misc*)?В зависимости от того, насколько строго документы соответствуют спецификации XML и собственным DTD-объявлениям, они могут быть хорошо оформленными (well-formed) и правильными (valid).
Хорошо оформленный документ соответствует всем синтаксическим правилам XML и некоторым дополнительным ограничениям, например:
□ имя открывающего тега элемента должно совпадать с именем его закрывающего тега;
□ имена атрибутов элемента не должны повторяться;
□ в значении атрибута нельзя использовать символ "
<□ сущности должны быть определены до использования;
□ сущности-параметры могут быть использованы только в блоках DTD;
□ документ должен иметь единственный корневой элемент, содержащий все остальные элементы и символьные данные этого документа. Вне корневого документа допускаются только комментарии, инструкции по обработке, декларация XML и блок DTD.
Правильные документы должны быть хорошо оформленными, и при этом их логическая структура должна удовлетворять объявлениям, которые содержатся в декларации типа документа (DTD).
Для того чтобы документ мог быть обработан различными приложениями стандартным образом, он должен как минимум быть хорошо оформленным. Выполнение этого требования означает, что документ корректен с точки зрения синтаксиса, и для его логического представления можно использовать любую из стандартных моделей. Например, если в элементе документа приведены два атрибута с одинаковыми именами, возможно, с точки зрения автора, это логично и корректно, однако, стандартными средствами такой документ обработать не удастся.
Требование правильности означает четкое соответствие выбранной логической схеме документа. Объявления декларации типа документа накладывают на логическую структуру документа определенные ограничения с тем, чтобы он мог быть стандартным образом обработан не только синтаксическими, но и семантическими процессорами, то есть программами, которые не только могут распознать синтаксис XML-документа, но и "понять" его смысл, переданный разметкой.
Использование технологии XML
Вряд ли удастся описать все множество приложений и задач, в которых можно успешно применять XML-технологии, однако существуют области, в которых использование XML стало уже классикой. Чуть ниже мы рассмотрим несколько наиболее типичных классов задач XML.
Пока же необходимо сказать следующее — несмотря на всю мощь XML, это далеко не панацея и не решение всех проблем, которые могут возникнуть. Нужно хорошо понимать, что XML — это всего лишь формат описания данных. Четкий, конкретный, независимый, мощный формат описания данных — но не более! XML-технологии могут решить проблемы представления, несоответствия синтаксиса семантике и многие другие проблемы организации данных в документе, но они не смогут решить чисто программистских задач — как обрабатывать эти документы. XML не имеет особого смысла вне прикладных задач.
В качестве типичного примера можно привести язык XSLT (язык расширяемых стилей для преобразований, extensible Stylesheet Language for Transformations), который находится в фокусе этой книги. Программы, написанные на XSLT, называются преобразованиями, и они являются в прямом смысле XML-документами, но при этом удовлетворяют логической схеме языка XSLT. При этом преобразования не имели бы смысла без XSLT-процессора, который может применять их к другим документам. Они были бы просто текстом.
Создание XML-документов без программного обеспечения, которое будет понимать их семантику — это все равно, что писать программы на языке программирования, для которого не существует трансляторов и интерпретаторов. Они могут быть безупречно корректными, но совершенно бесполезными.
Стандартизированный и совсем не сложный синтаксис XML позволил многим компаниям разработать средства для синтаксического разбора XML-документов. Программы такого рода называют XML-парсерами (англ. parse — разбирать, анализировать). В настоящее время существует два основных типа XML-парсеров: SAX-парсеры и DOM-парсеры. Оба типа широко используются в различных приложениях — парсеры избавляют от необходимости писать собственные синтаксические анализаторы, штудировать спецификации и так далее. Мы коротко опишем каждый из этих типов.
SAX-парсеры
SAX расшифровывается как Simple API for XML, что означает буквально "Простой прикладной интерфейс программирования для XML". Это так и есть — идеология SAX очень проста. Программист должен описать, как следует обрабатывать ту или иную конструкцию документа, а парсер при обработке документа уже сам будет выполнять соответствующие действия. Иными словами, обработка документа производится в виде реакции на события, которые возникают, когда парсер встречает в документе тот или иной элемент, атрибут, комментарий и так далее.
В отличие от DOM-парсеров, SAX-парсеры не создают никакого внутреннего представления документа, оставляя эту задачу на совести программиста. Вследствие этого SAX-парсеры менее требовательны к ресурсам, что часто бывает критичным. Однако это никак не сказывается на их функциональности, таким образом SAX-парсеры являются незаменимыми инструментами для синтаксического разбора XML-документов. Зачастую, более сложные DOM-парсеры используют SAX как составную часть.
DOM-парсеры
Как уже было упомянуто абзацем выше, легкие SAX-парсеры не создают внутреннего представления ХМL-документов, вполне справедливо считая, что этим придется заняться программисту.
Вместе с тем, древовидная организация данных в ХМL-документах настолько очевидна, что внутренние представления, которые использовались в совершенно разных приложениях, совпадали практически в точности. Такая ситуация привела к решению разработать единый интерфейс не для обработчика документа, как это было сделано в SAX, а для внутреннего представления XML-документа целиком.
Набор таких интерфейсов получил название DOM (document object model, объектная модель документа). DOM-парсер обрабатывает документ, создавая при этом его внутреннее объектное представление. При этом DOM содержит только определения интерфейсов, никоим образом не регулируя внутреннюю реализацию самой модели документа. Все обращения к данным и структуре, которыми обладает документ, происходят посредством вызова методов, определенных в соответствующих интерфейсах.
Объектную модель документа полезно использовать там, где требуется работать с документом целиком, как с деревом. Представление всего документа будет занимать в памяти значительный объем, поэтому DOM резонно считается моделью, очень требовательной к ресурсам.
При выборе парсера необходимо хорошо понимать задачи, которые нужно будет решать при обработке документа. Во многих случаях совершенно необязательно целиком представлять документ в памяти. Будет вполне достаточным создать обработчик документа, и затем, при помощи SAX-парсера, произвести обработку без особых затрат ресурсов. Если же, напротив, при обработке важно иметь модель всего документа целиком, лучше использовать готовое решение в виде DOM-парсера.
Основные классы задач XML
В этой главе мы разберем несколько основных типов задач, для решения которых целесообразно применять 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
Вряд ли удастся описать все множество приложений и задач, в которых можно успешно применять XML-технологии, однако существуют области, в которых использование XML стало уже классикой. Чуть ниже мы рассмотрим несколько наиболее типичных классов задач XML.
Пока же необходимо сказать следующее — несмотря на всю мощь XML, это далеко не панацея и не решение всех проблем, которые могут возникнуть. Нужно хорошо понимать, что XML — это всего лишь формат описания данных. Четкий, конкретный, независимый, мощный формат описания данных — но не более! XML-технологии могут решить проблемы представления, несоответствия синтаксиса семантике и многие другие проблемы организации данных в документе, но они не смогут решить чисто программистских задач — как обрабатывать эти документы. XML не имеет особого смысла вне прикладных задач.
В качестве типичного примера можно привести язык XSLT (язык расширяемых стилей для преобразований, extensible Stylesheet Language for Transformations), который находится в фокусе этой книги. Программы, написанные на XSLT, называются преобразованиями, и они являются в прямом смысле XML-документами, но при этом удовлетворяют логической схеме языка XSLT. При этом преобразования не имели бы смысла без XSLT-процессора, который может применять их к другим документам. Они были бы просто текстом.
Создание XML-документов без программного обеспечения, которое будет понимать их семантику — это все равно, что писать программы на языке программирования, для которого не существует трансляторов и интерпретаторов. Они могут быть безупречно корректными, но совершенно бесполезными.
Стандартизированный и совсем не сложный синтаксис XML позволил многим компаниям разработать средства для синтаксического разбора XML-документов. Программы такого рода называют XML-парсерами (англ. parse — разбирать, анализировать). В настоящее время существует два основных типа XML-парсеров: SAX-парсеры и DOM-парсеры. Оба типа широко используются в различных приложениях — парсеры избавляют от необходимости писать собственные синтаксические анализаторы, штудировать спецификации и так далее. Мы коротко опишем каждый из этих типов.
SAX-парсеры
SAX расшифровывается как Simple API for XML, что означает буквально "Простой прикладной интерфейс программирования для XML". Это так и есть — идеология SAX очень проста. Программист должен описать, как следует обрабатывать ту или иную конструкцию документа, а парсер при обработке документа уже сам будет выполнять соответствующие действия. Иными словами, обработка документа производится в виде реакции на события, которые возникают, когда парсер встречает в документе тот или иной элемент, атрибут, комментарий и так далее.
В отличие от DOM-парсеров, SAX-парсеры не создают никакого внутреннего представления документа, оставляя эту задачу на совести программиста. Вследствие этого SAX-парсеры менее требовательны к ресурсам, что часто бывает критичным. Однако это никак не сказывается на их функциональности, таким образом SAX-парсеры являются незаменимыми инструментами для синтаксического разбора XML-документов. Зачастую, более сложные DOM-парсеры используют SAX как составную часть.
DOM-парсеры
Как уже было упомянуто абзацем выше, легкие SAX-парсеры не создают внутреннего представления ХМL-документов, вполне справедливо считая, что этим придется заняться программисту.
Вместе с тем, древовидная организация данных в ХМL-документах настолько очевидна, что внутренние представления, которые использовались в совершенно разных приложениях, совпадали практически в точности. Такая ситуация привела к решению разработать единый интерфейс не для обработчика документа, как это было сделано в SAX, а для внутреннего представления XML-документа целиком.
Набор таких интерфейсов получил название DOM (document object model, объектная модель документа). DOM-парсер обрабатывает документ, создавая при этом его внутреннее объектное представление. При этом DOM содержит только определения интерфейсов, никоим образом не регулируя внутреннюю реализацию самой модели документа. Все обращения к данным и структуре, которыми обладает документ, происходят посредством вызова методов, определенных в соответствующих интерфейсах.
Объектную модель документа полезно использовать там, где требуется работать с документом целиком, как с деревом. Представление всего документа будет занимать в памяти значительный объем, поэтому DOM резонно считается моделью, очень требовательной к ресурсам.
При выборе парсера необходимо хорошо понимать задачи, которые нужно будет решать при обработке документа. Во многих случаях совершенно необязательно целиком представлять документ в памяти. Будет вполне достаточным создать обработчик документа, и затем, при помощи SAX-парсера, произвести обработку без особых затрат ресурсов. Если же, напротив, при обработке важно иметь модель всего документа целиком, лучше использовать готовое решение в виде DOM-парсера.
Основные классы задач XML
В этой главе мы разберем несколько основных типов задач, для решения которых целесообразно применять XML. Естественно, этот список даже близко не претендует на полноту, так же, как нельзя, например, перечислить все программы, которые можно написать на языке Java. Несколько примеров предметных областей, которые будут приведены, иллюстрируют классические проблемы, с успехом решенные XML-технологиями.
Создание новых языков
Хотя мы и говорим об XML, как о формате описания данных, на самом деле XML — это метаязык, язык, который описывает другие языки. Строго говоря, когда мы создаем XML-документ, мы создаем его не на XML, а в соответствии с XML-синтаксисом. XML — это всего лишь набор синтаксических правил, не более. Настоящим языком в этой ситуации является то, что мы понимаем под логической, семантической схемой создаваемого документа.
Таким образом, каждый раз, когда мы описываем логическую схему документа, мы создаем новый язык с придуманной нами семантикой и XML-синтаксисом. Достоинством XML в данном случае является стандартность этого синтаксиса, поскольку заботиться о создании модуля для синтаксического разбора (парсера) уже не нужно.
Что же касается семантики языка, то во многих случаях древовидные XML-структуры очень хорошо подходят для ее описания, будь это язык формата документа или язык программирования.
Главным недостатком XML является громоздкость синтаксиса. Например, арифметическое выражение
2*2 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
Краткая история XML
XML основывается на принципах и соглашениях двух существующих языков разметки, XML и SGML, каждый из которых получил широкое распространение и успешно использовался для решения своего круга задач.
Несмотря на то, что идеи обобщенной разметки начали появляться еще в 60-х годах, SGML (standard generalized markup language, стандартный язык обобщенной разметки) был ратифицирован Международной Организацией Стандартизации (ISO) только в 1986 году. Возможно, будет показательным тот факт, что SGML не требовал изменений в течение, практически, 10 лет — настолько мощным инструментом он был.
Вместе с тем, на определенном этапе мощь SGML стала становиться препятствием — этот язык был настолько сложен, что поддержка в приложениях даже основного его подмножества оказалась непростой задачей. Это сказывалось на скорости разработки, стабильности и стоимости приложений, и потому, все больше и больше экспертов высказывались за упрощение этого языка.
Примерно в то же время произошел квантовый скачок в другой области информационных технологий. Развитие сетевых технологий вывело инфраструктуру обмена информации на качественно новый уровень, произведя на свет глобальную сеть Интернет. Интернет, в свою очередь, стал платформой для обмена гипертекстовыми документами, которые также нуждались в простом стандартном языке разметки для базового форматирования текста, создания таблиц и гиперссылок. Для этих целей был разработан HTML — язык разметки гипертекста (hypertext markup language).
HTML основывался на синтаксисе SGML, принципы этой технологии были практически проигнорированы. Только намного позже HTML стал SGML- совместимым языком. Ограниченность и нерасширяемость HTML вела к тому, что производители браузеров (программ просмотра) вводили собственные, в большинстве случаев несовместимые, расширения, что в итоге привело к довольно плачевной ситуации в этой области.
Потребность в улучшении HTML совпала с потребностью в упрощении SGML. В 1996 году Консорциум W3 (World Wide Web Consortium, W3C) поддержал группу Web SGML Activity, задачей которой было создание нового языка разметки, более мощного, чем HTML, но более простого, чем SGML.
Разработка началась с определения десяти положений, которым должен был соответствовать новый язык. Хотя эти положения и не являются определяющими для уже созданного языка, они все еще включаются в официальную спецификацию XML (п. 1). Думается, будет довольно интересно сравнить первоначальные устремления с тем, что получилось на самом деле. Попытаемся подробнее рассмотреть десять положений XML.
1. XML должен напрямую использоваться в сети Интернет. Возможно, XML еще долго не будет использоваться в Интернет, как основной язык разметки (сказывается огромная инертность технологий), но, во всяком случае, авторы попытались по максимуму учесть в XML особенности языка HTML.
2. XML должен поддерживать разнообразные приложения. Как уже было описано выше, XML можно использовать в самых разных областях — тут сказывается мощь абстракции, которую предоставляет древовидные представления данных.
3. XML должен быть совместим с SGML. XML был разработан, как подмножество языка SGML, и для его обработки можно использовать любые SGML-продукты.
4. Разработка программ для обработки XML-документов не должна быть сложной задачей. Конструктивный синтаксис XML намного проще, по сравнению с SGML, а значит, XML-инструменты также проще разрабатывать и использовать в своих решениях.
5. Количество необязательных особенностей XML должно быть как можно меньше, в идеале их не должно быть вовсе. Сложно сказать, насколько это положение было выполнено — ведь большинство особенностей в XML являются необязательными. С другой стороны, в XML, как правило, существует только один способ добиться желаемого эффекта — в этом смысле опций, действительно, немного.
6. XML-документы должны быть понятны человеку, и при этом достаточно ясны. Как мы уже могли убедиться, XML-документы имеют простую и понятную форму.
7. XML должен быть разработан быстро. Разработчикам понадобилось два года — с 1996 по 1998, чтобы создать XML — значительный срок для довольно простого языка.
8. Спецификация XML должна быть формальной и лаконичной. Синтаксис языка XML однозначно определяется EBNF-правилами, а сама спецификация не имеет двояких толкований.
9. XML-документы должны легко создаваться. Поскольку UTF-8, основная форма кодирования XML-документов, совместима с ASCII, для редактирования XML-документов можно использовать все множество инструментов для работы с обычными текстовыми файлами.
10. Лаконичность разметки XML-документов не является важной. Язык SGML позволял авторам документов опускать части разметки в случаях, когда из контекста ясно, что там должно быть. Подобный принцип был использован в HTML, где в некоторых случаях можно опускать закрывающие теги, например,
Главную роль в создании XML приписывают техническому гуру из фирмы Sun, Йону Босаку (Jon Bosak). Босак и его команда сделали с SGML примерно то же, что когда-то сделала команда, создававшая язык Java с языком С++. Язык был упрощен, сложные и редко использующиеся его особенности были упразднены. Первая спецификация языка, редакторами который были Тим Брэй (Tim Bray) и С.М. Шперберг-МакКвин (С.М. Sperberg-McQueen), в общей сложности насчитывала 26 страниц, что примерно в 20 раз меньше по объему стандарта SGML.
В октябре 2000 года с небольшими изменениями была принята вторая редакция спецификации языка XML. Судя по всему, язык оказался настолько удачным, что пройдет довольно значительное время прежде, чем он будет изменен.
Будущее XML практически гарантировано. Несмотря на всю поднятую маркетинговую шумиху, в которой XML — не более чем "buzzword", расхожее словечко, нельзя игнорировать два следующих обстоятельства. Во-первых, без сомнения, существует огромная потребность в простом языке обобщенной разметки, и, во-вторых, у XML просто нет конкурентов. Большие компании уже приняли XML, как стандартное средство, в составе многих своих решений, и вряд ли какая другая технология сможет в скором времени вытеснить этот язык.
Вместе с тем, было бы ошибкой считать, что XML пришел на замену HTML и SGML. Совсем нет — XML занимает те ниши, которые ранее были недоступны этим двум языкам. В информационном мире всегда будет место для каждого из них, хотя, вполне закономерно ожидать, что XML-технологии получат со временем гораздо более широкое распространение, чем HTML и SGML вместе взятые.
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги