Одной из главных задач технологии XML было отделение данных от их презентации. XML прекрасно справляется с этой задачей, предоставляя широкие возможности для структурного оформления данных в текстовом виде. Вместе с тем, во многих случаях просто выделить данные было явно недостаточно, поскольку помимо машинной обработки они также должны были быть понятны человеку. В качестве примера, вспомним рекламное объявление, которое мы разметили в первой главе:
Предлагаем Вашему вниманию новый 3 -x камерныйХолодильник "Горск" объемом 250 л. и стоимостью всего 4500 рублей!Разметив документ, оформив семантически значимые данные при помощи элементов, мы добились явного выделения их структуры, что позволяет программно обрабатывать информацию, содержащуюся в документе (например, производить поиск или анализ данных). Но это только полдела: помимо программной обработки рекламных объявлений, не менее важной задачей является их презентация, ведь в большинстве случаев пользователь хочет увидеть объявление, а не получить соответствующую ему структуру данных.
Выделение данных, вне всякого сомнения, расширяет возможности презентации, поскольку они более не зависят от конкретного устройства или формата вывода. Единственное требование — это наличие программных средств, которые, принимая на вход структурированную информацию, смогут корректным образом представить ее в целевом формате или носителе. Если вернуться к примеру с рекламным объявлением, то для того, чтобы получить вывод этого объявления в формате HTML, нам потребуется программа, которая поймет формат документа объявления и создаст для него соответствующий гипертекстовый файл.
При всем многообразии возможных методов презентации данных, наиболее часто используемые из них весьма схожи между собой. Примером этому может служить визуальное представление информации в печатной форме или на экране.
Приведенные выше причины могут объяснить потребность в стандартной технологии для презентации XML-документов — технологии, подобной DSSSL (Document Style Semantics and Specification Language, язык семантики и спецификации стиля документа), которая существовала для SGML или CSS (Cascading Style Sheets — каскадные таблицы стилей) для HTML. Эта технология получила название XSL (extensible Stylesheet Language — расширяемый язык стилей), и именно ей обязан своим возникновением язык XSLT.
Первые идеи о создании отдельного языка для презентации документов были представлены на конференции WWW'94, где С.М. Шперберг-МакКвин и Роберт Гольдштейн выступили с докладом об использовании возможностей SGML во всемирной паутине. В этом докладе были сформулированы основные принципы языка стилей. Мы перечислим некоторые из них:
□ язык стилей должен быть декларативным (а не процедурным);
□ язык стилей должен уметь оперировать структурой документа;
□ презентация элемента может изменяться в зависимости от расположения этого элемента в документе;
□ реализация интерпретатора языка стилей не должна быть сложной даже в процедурном языке программирования;
□ синтаксис языка должен быть как можно более примитивным, чтобы разбор его грамматических конструкций не составлял труда.
Спустя три года, когда Консорциум W3 уже всерьез занялся концепцией XML, эти идеи получили дальнейшее развитие: началась разработка XSL, языка для презентации XML-документов.
Язык XSL виделся тогда более простым и понятным, чем DSSSL и более мощным, чем CSS. Уже тогда разработчики понимали, что язык презентации XML-документов не сможет обойтись без преобразования их структуры, расширений и должен быть основан на множестве правил презентации.
В мае 1998 года требования к XSL были оформлены в едином документе. Помимо большого числа комментариев, касающихся визуальной презентации XML-документа, этот документ также упоминал необходимость определения вычислительных выражений, операций, типов данных, конструкций, которые позволяли бы обращаться к обрабатываемому документу, стандартных и пользовательских функций. Концептуально язык определялся как декларативный и не имеющий побочных эффектов.
После того, как требования к XSL были, наконец, сформулированы, разработка языка вылилась в создание целой серии черновых рабочих вариантов (в терминах W3C — working drafts, WD). Эти варианты зачастую сильно различались между собой, однако основные принципы XSL соблюдались в них неукоснительно.
С первых же рабочих версий XSL стало понятно, что задача презентации XML-документов состоит из двух главных подзадач: преобразование документа и описание внешнего вида результата этого преобразования. Разделение это было настолько четким, что спецификацию XSL более или менее независимо редактировали два человека: Джеймс Кларк (James Clark) и Стивен Дич (Stephen Deach). Кларк отвечал за преобразования (что в первых версиях называлось tree construction — конструирование дерева), Дич редактировал презентационную часть XSL (которую назвали formatting objects — форматирующие объекты).
Независимость и различия между двумя этими частями были настолько явными, что уже в третьей рабочей версии, которая вышла в свет 21 апреля 1999 года, технологию XSL разделили на два языка: XSL (расширяемый язык стилей) и XSLT (расширяемый язык стилей для преобразований). XSLT отвечал за преобразование входящего документа, XSL — за визуальное отображение результата этого преобразования. В дальнейшем эти два языка стали развиваться достаточно независимо (хотя они и были частями одной технологии).
Следующим важным моментом в истории XSLT было создание языка XPath (вернее, выделение этого языка, как самостоятельного). Как оказалось, XSLT имеет семантически общую часть с языком XPointer, который разрабатывался другой группой Консорциума W3. Результатом общих усилий был создан язык XPath, который позволял обращаться к частям XML-документов, а также производить выборки и основные вычисления. XPath также обладал базовой библиотекой функций, которую и XSLT и XPointer расширяли для собственных нужд.
Таким образом, технология XSL разделилась на три составные части: язык преобразований XSLT, язык обращений к XML-документам XPath и язык стилей XSL. На рис. 2.12 в графической форме показано развитие XSL с момента создания первой рабочей версии в августе 1998 года и до настоящего времени. Вершины графа соответствуют опубликованным версиям языков. WD означает working draft (рабочий черновой вариант), CR — candidate recommendation (кандидат в рекомендации), PR — proposed recommendation (предлагаемая рекомендация) и REC — рекомендация. Для тех, кто не знаком с деятельностью Консорциума W3 поясним, что любая технология, которой занимаются рабочие группы W3C, проходит ряд этапов: формирования требований, несколько рабочих версий, кандидат в рекомендации и предлагаемая рекомендация. Если все проходит успешно, технология становится технической рекомендацией Консорциума W3, что имеет статус стандарта де-факто (с тем лишь отличием, что стандарты могут принимать только организации, уполномоченные правительствами).
Рис. 2.12. История развития языка XSL в виде графа
Что касается XSLT и XPath, спецификации обоих этих языков стали техническими рекомендациями 16 ноября 1999 года. Сам же язык XSL, который теперь стали называть XSL-FO (аббревиатура FO означает formatting objects — форматирующие объекты), получил статус рекомендации не так быстро. Спустя год, в ноябре 2000, спецификация XSL получила статус кандидата в рекомендации, а еще через 9 месяцев с минимальными исправлениями — статус предлагаемой рекомендации. По всей видимости, к тому моменту, когда эта книга увидит свет, спецификация XSL уже будет официальной рекомендацией W3C.
Одного года было достаточно, чтобы XSLT стал широко использоваться во многих XSLT-задачах. Повышенное внимание разработчиков позволило выявить некоторые досадные огрехи, которые были допущены в первой версии XSLT, и потому в конце 2000 года была начата работа над версией 1.1. В новой версии рабочая группа XSL постаралась исправить большинство ошибок, допущенных в версии 1.0 и добавить некоторые возможности, которых не хватало в первой версии. Однако через некоторое время стало понятно, что разрабатываемый язык довольно сильно отличается от первой версии. К тому же, с учетом таких разработок, как XML Schema и XQuery возникла необходимость изменить модель данных и выражений XPath. В итоге, работу над версией 1.1 решено было прекратить и переключиться на создание вторых версий языков XSLT и XPath.
Вместо того чтобы разбирать в этой книге особенности версии 1.1, которая никогда не станет рекомендацией, в последней главе мы опишем то, что, согласно требованиям ко вторым версиям языков XSLT и XPath, ожидается в их спецификациях, и что, согласно XSLT 1.1 там точно будет. Работа над XSLT 2.0 и XPath 2.0 в самом разгаре: к сентябрю 2001 года были уже готовы три внутренних рабочих версии. К сожалению, открывать секреты рабочей группы XSL мы не в праве, хотя можно смело сказать, что процесс работы внушает оптимизм.
Глава 3Идея и модель языка XSLT
Модель XML-документа
Описывая основы построения XML-документов, мы отмечали, что иерархическая организация информации в XML лучше всего описывается древовидными структурами. Дерево — это четкая, мощная и простая модель данных и именно она была на концептуальном уровне применена в языках XSLT и XPath. Как пишет Кнут [Кнут 2000], "деревья — это наиболее важные нелинейные структуры, которые встречаются при работе с компьютерными алгоритмами". Добавим, что это без сомнения самая важная структура из тех, которыми оперируют языки XSLT и XPath.
В этих языках документ моделируется как дерево, состоящее из узлов. Узлы дерева соответствуют структурным единицам XML — элементам, атрибутам, тексту и так далее, а дуги, ветки — отношениям между этими единицами. Простейшим примером является принадлежность одних элементов другим. Документ вида
<а><с/>может быть представлен деревом (рис. 3.1).
Рис. 3.1. Представление документа в виде дерева
Аналогия совершенно очевидна — элемент
аbсаbсЕстественно, XML-документы состоят далеко не из одних только элементов и потому для того, чтобы дерево достоверно отражало структуру и содержание документа, в нем выделяются узлы следующих семи типов:
□ корневой узел;
□ узлы элементов;
□ узлы атрибутов;
□ текстовые узлы;
□ узлы пространств имен;
□ узлы инструкций по обработке;
□ узлы комментариев.
Каждый узел дерева имеет соответствующее ему строковое значение, которое вычисляется в зависимости от типа. Строковым значением корневого узла и узла элемента является конкатенация (строковое сложение) строковых значений всех их потомков, для остальных типов узлов строковое значение является частью самого узла. Порядок вычисления строковых значений узлов будет более детально определен в описании каждого из типов.
Мы подробно разберем каждый из типов узлов чуть позже, а пока отметим, что дерево в XSLT и XPath является чисто концептуальной моделью. Процессоры не обязаны внутренне представлять документы именно в этой структуре, концептуальная модель означает лишь то, что все операции преобразования над документами будут определяться в терминах деревьев. Для программиста же это означает, что вовсе необязательно вникать в тонкости реализации преобразований в том или ином процессоре. Все равно они должны работать, так, как будто они работают непосредственно с деревьями.
Отметим также и то, что на практике некоторые из процессоров вообще не воссоздают внутреннюю модель документа, экономя, таким образом, ресурсы. Документы могут быть слишком объемными, и это препятствует загрузке их в память в виде древовидной структуры.
Некоторые из процессоров, напротив, используют DOM-модель документа для внутреннего представления обрабатываемой информации. Несмотря на большие требования к ресурсам памяти, такое решение также может иметь свои плюсы, например, универсальность и легкая интеграция в существующие XML-решения на базе DOM.
Но, так или иначе, с воссозданием древовидной структуры документа в памяти или нет, процессоры все равно оперируют одной и той же концептуальной моделью, которой мы сейчас и займемся.
Деревья
Прежде, чем мы приступим к рассмотрению типов узлов и отношений между ними, необходимо определиться с самой структурой дерева. Древовидная структура задает для своих элементов отношение ветвления, очень похожее на строение обычного дерева — есть корневой узел (ствол), от которого происходят другие узлы (ветки).
Формально [Кнут 2000] дерево определяется, как конечное множество T, состоящее из одного или нескольких элементов (узлов), обладающих следующими свойствами:
□ во множестве T выделяется единственный узел, называемый корневым узлом или корнем;
□ все остальные узлы разделены на m≥0 непересекающихся множеств T1, …, Tm, каждое из которых в свою очередь также является деревом.
Деревья T1, …, Tm называются поддеревьями корня дерева T.
Это определение является рекурсивным, то есть в нем дерево определяется само через себя. Конечно, существуют нерекурсивные определения, но, пожалуй, следует согласиться с тем, что рекурсивное определение лучше всего отражает суть древовидной структуры: ветки дерева также являются деревьями.
В XSLT и XPath деревья являются упорядоченными, то есть для множеств T1, …, Tm задается порядок следования, который называется порядком просмотра документа. В XSLT деревья упорядочиваются в порядке появления текстового представления их узлов в документах.
Существует множество способов графического изображения деревьев. Мы будем рисовать их так, что корень дерева будет находиться наверху, а поддеревья будут упорядочены слева направо. Такой способ является довольно стандартным для XML, хотя и здесь существует множество вариантов. Примером изображения дерева может быть следующий рисунок (рис. 3.2):
Рис. 3.2. Изображение дерева
Мы часто будем говорить о дочерних узлах, родительских узлах, братских узлах, узлах-предках и узлах-потомках. Дадим определения этим понятиям.
□ Дочерним узлом текущего узла называется любой из корней его поддеревьев. Например, в дереве на рис. 3.2 дочерними узлами узла
асbdeс□ Каждый узел называется родительским узлом корней своих поддеревьев. На рис. 3.2 узел
аbсbde□ Корни поддеревьев называются братскими узлами или узлами-братьями. На рис. 3.2 братьями являются узлы
bсd e□ Предками текущего узла являются его родитель, а также родители его родителей и так далее. На рис. 3.2 предками узла
dbа□ Потомками текущего узла являются его дочерние узлы, а также дочерние узлы его дочерних узлов и так далее. На рис. 3.2 потомками узла
аbcdeУзлы дерева XML-документа
Корневой узел
Корневой узел XML-документа — это узел, который является корнем дерева документа. Не следует путать его с корневым элементом документа, поскольку помимо корневого элемента дочерними узлами корня также являются инструкции по обработке и комментарии, которые находятся вне корневого элемента.
Мы будем помечать корневой узел документа символом "
/Рис. 3.3. Изображение корневого узла
На рис. 3.4 показано изображение документа,
<В/>корневой узел которого помимо корневого элемента содержит комментарии и инструкции по обработке.
Рис. 3.4. XML-документ и его изображение
Корневой элемент не имеет имени. Функция
name(/)Строковым значением корневого узла является конкатенация строковых значений всех его текстовых потомков в порядке просмотра документа.
Узлы элементов
Каждому элементу XML-документа соответствует узел элемента. Дочерними узлами узла элемента могут быть узлы его дочерних элементов, а также узлы комментариев, инструкций по обработке и текстовые узлы, которые представляют его непосредственное содержимое. Следует обратить внимание на то, что узлы атрибутов не считаются дочерними узлами своего элемента, они лишь только ассоциируются с ними.
При изображении деревьев мы будем помечать узлы элементов их именами. Например, элемент
AРис. 3.5. Изображение элемента
АКаждый элемент имеет расширенное имя, которое состоит из локальной части и идентификатора пространства имен. Пространство имен, которому принадлежит элемент, может быть нулевым, если элемент не имеет префикса, и в его предках не было объявлено пространство имен по умолчанию.
Подобно корневому узлу, строковым значением узла элемента будет конкатенация значений его текстовых потомков в порядке просмотра документа. В силу того, что атрибуты не являются потомками элементов, их текстовые значения учитываться не будут.
Узлы атрибутов
Атрибутам того или иного элемента соответствуют узлы атрибутов. Считается, что узел элемента является родителем узла своего атрибута, но вместе с тем узел атрибута не является дочерним узлом узла его элемента. Такая ситуация несколько отличает дерево документа в XSLT от классического дерева, как оно было определено ранее — отношение между узлом элемента и узлом атрибута является отношением ассоциации. Говорят, что узел атрибута ассоциируется с узлом элемента.
Между тем, отношения такого рода не сильно отличаются от отношений между родительскими и дочерними узлами — один атрибут ассоциируется ровно с одним элементом. Поэтому мы будем изображать узлы атрибутов точно так же, как если бы они были дочерними узлами элементов. Для того чтобы отличать узлы атрибутов от остальных узлов, мы будем помечать их именем, которому будет предшествовать символ "
@Рис. 3.6 показывает возможные варианты изображения элемента, определенного как
Рис. 3.6. Изображение элемента и принадлежащего ему атрибута
В случаях, когда значение атрибута не является важным, оно может отсутствовать в изображении узла.
Каждый атрибут имеет расширенное имя, состоящее из локальной части и идентификатора пространства имен. Пространство имен атрибута будет нулевым, если оно не было определено по умолчанию и у имени атрибута нет префикса.
Строковым значением узла атрибута является значение атрибута, который ему соответствует.
Текстовые узлы
Символьные данные, содержащиеся в документе, организуются в виде текстовых узлов. Последовательности символов, встречающиеся в документах, в целях экономии никогда не разбиваются на два или более текстовых узла, а текстовые узлы никогда не бывают пустыми. Содержание секций CDATA обрабатываются так, как если бы их содержимое было просто включено в документ с заменой символов "
<&<&Текст, содержащийся в значениях атрибутов, а также в комментариях и инструкциях по обработке не оформляется в виде текстовых узлов — эти данные принадлежат соответствующим узлам атрибутов, комментариев и инструкций.
Мы будем помечать текстовые узлы символьными последовательностями, которые они содержат, заключенными в кавычки. В случаях, когда сам текст не важен, мы будем помечать эти узлы как "
...Элемент, заданный как
Welcome
Рис. 3.7. Варианты изображения текстового узла элемента
Текстовые узлы не имеют имен. Строковым значением текстового узла является последовательность символов, которую он содержит.
Узлы пространств имен
Каждому пространству имен, которое определено для данного элемента, соответствует узел пространства имен, ассоциируемый с узлом этого элемента. Множество узлов пространств имен, которое ассоциируется с данным элементом, включает в себя следующие узлы.
□ Узел, который соответствует пространству имен
xml□ Узел, который соответствует пространству имен, заданному по умолчанию, если такое есть.
□ По одному узлу на каждый префикс пространств имен, доступный в данном элементе.
Напомним, что пространства имен, доступные в данном элементе, и пространство имен по умолчанию могут быть определены в его предках.
Подобно узлам атрибутов, узлы пространств имен ассоциируются с узлом элемента. Узел элемента является их родительским узлом, но при этом они сами не являются дочерними узлами узла элемента.
Расширенные имена узлов пространств имен состоят из локальной части имени, которая равна префиксу, использованному для объявления этого пространства и нулевого идентификатора пространства имен. Локальная часть пространства, определенного по умолчанию, будет пустой.
Строковым значением узла пространства имен является уникальный идентификатор ресурса (URI), с которым оно связано.
Мы будем помечать узлы пространств имен метками вида
xmlns:префиксxmlnsxmlПриведем изображение дерева (рис. 3.8) документа
<а xmlns="urn:a">Рис. 3.8. Изображение дерева документа с узлами пространств имен
Узлы инструкций по обработке
Каждой инструкции по обработке соответствует свой узел. В дерево не включаются узлы инструкций, которые были приведены в декларации типа документа (DTD). Кроме этого, поскольку декларация XML не является инструкцией по обработке, ей не будет соответствовать никакой узел в дереве документа.
Локальной частью расширенного имени инструкции по обработке является имя целевого приложения инструкции. Пространство имен инструкции по обработке всегда нулевое.
Строковым значением инструкции по обработке является ее содержание — последовательность символов, которая начинается после имени приложения и следующего за ним пробела и заканчивается перед символами "
?>Узел инструкции по обработке помечается именем целевого приложения, заключенным в символы "
?>Узел инструкции по обработке
Рис. 3.9. Изображение узла инструкции по обработке
Узел комментария
Узел комментария соответствует каждому из комментариев, которые присутствуют в документе кроме тех, которые находятся в декларации типа документа (DTD). Узлы комментариев не имеют имен; их строковым значением является текст комментария — последовательность символов после "
Узел комментария
Рис. 3.10. Изображение узла комментария
Сводная таблица характеристик узлов
Для удобства использования мы можем свести в одну таблицу (табл. 3.1) такие характеристики узлов, как строковое значение, локальная часть имени, пространство имен и так далее.
Таблица 3.1. Характеристики различных типов узлов
| Тип узла | Характеристики | ||||
|---|---|---|---|---|---|
| Строковое значение | Расширенное имя | Дочерние узлы | Родительские узлы | ||
| Локальная часть имени | Пространство имен | ||||
| Корневой узел | Конкатенация текстовых потомков | Нет | Узлы элементов, комментариев, инструкций по обработке | Нет | |
| Узел элемента | Конкатенация текстовых потомков | Имя элемента | Пространство имен элемента | Узлы элементов, комментариев, инструкций по обработке, текстовые узлы | Корневой узел или узел элемента |
| Узел атрибута | Значение атрибута | Имя атрибута | Пространство имен атрибута | Нет | Узел элемента |
| Текстовый узел | Символьные данные | Нет | Нет | Узел элемента | |
| Узел пространства имен | URI пространства имен | Префикс пространства имен | Нулевое | Нет | Узел элемента |
| Узел инструкции по обработке | Содержимое инструкции | Имя целевого приложения | Нулевое | Нет | Корневой узел или узел элемента |
| Узел комментария | Текст комментария | Нет | Нет | Корневой узел или узел элемента |
Ограничения модели XML-документа
Модель XML-документа, описанная выше, является вполне достаточной для того, чтобы манипулировать структурой документа и данными, которые он содержит. Между тем, эта модель имеет определенные ограничения, а именно:
□ Не учитывается информация, содержащаяся в блоке DTD. Как следствие, в XSLT невозможно манипулировать определениями сущностей, элементов, атрибутов и так далее.
□ Не учитываются некоторые синтаксические особенности входящего XML-документа. Например: использовались ли в определенном атрибуте одинарные или двойные кавычки; была ли определенная строка задана сущностью или просто текстом, был ли текст заключен в секции CDATA или нет.
□ Если атрибут элемента был определен в DTD со значением по умолчанию, то в преобразовании нельзя точно сказать, присутствовал ли он физически во входящем документе или нет.
□ Не учитывается, был ли пустой элемент определен как
Одним словом, предложенная выше модель не учитывает информацию, которая не важна с точки зрения структуры документа. На практике помимо структуры бывает также важен и детальный синтаксис документа (например, необходимо вместо
Порядок просмотра документа
Узлы дерева XML-документа находятся в определенном порядке, который называется порядком просмотра документа (англ. document order). Этот порядок важен для вычисления XPath-вырэжений, которые оперируют множествами узлов. Несмотря на то, что эти множества не имеют внутреннего порядка, при вычислении выражений узлы в них будут перебираться в прямом или обратном порядке просмотра документа в зависимости от того, какие оси навигации применяются в выражении.
Порядок просмотра документа — это порядок, который соответствует появлению в документе первого символа текстовой записи узла. Например, для элементов это будет порядок появления в документе открывающих тегов.
Более четко порядок просмотра документа определяется следующими правилами:
□ корневой узел является первым узлом в порядке просмотра документа;
□ узлы элементов предшествуют своим дочерним узлам, узлам пространств имен и узлам атрибутов;
□ узлы пространств имен предшествуют узлам атрибутов;
□ узлы атрибутов предшествуют другим дочерним узлам своего элемента;
□ остальные узлы упорядочиваются в последовательности их появления в документе.
Обратным порядком просмотра документа называется порядок, который в точности противоположен обычному порядку просмотра документа. Обычный порядок просмотра документа также называют прямым порядком или порядком документа.
В качестве примера приведем схему дерева и выясним порядок просмотра
следующего документа:
<а level="0" xmlns:b="urn:b" xmlns="urn:a"> alpha deltaДерево этого документа показано на рис. 3.11. Порядок просмотра данного документа будет следующим:
□ корневой узел;
□ узел комментария
□ узел инструкции по обработке
□ узел элемента
a□ узел пространства имен
"urn:а"□ узел пространства имен
"urn:b"□ атрибут
level□ текстовый узел "
alpha□ узел элемента
b:bravo□ узел пространства имен
"urn:а"□ узел пространства имен
"urn:b□ комментарий с текстом "
To do ...□ элемент
charlie□ узел пространства имен
"urn:а"□ узел пространства имен
"urn:b"□ текстовый узел "
delta□ узел инструкции по обработке
Рис. 3.11. Схема дерева XML-документа
Соответственно, обратный порядок просмотра документа будет начинаться с инструкции по обработке
Типы данных