Книга состоит из двенадцати глав и четырех приложений, содержание которых мы кратко опишем ниже.

Первая глава книги об XSLT не случайно посвящена языку XML (от англ. extensible Markup Language — расширяемый язык разметки). XML — это фундаментальная концепция, по отношению к которой XSLT является прикладной технологией и поэтому для эффективного применения XSLT нужно хорошо понимать основы XML.

Мы разделяем мнение множества экспертов о том, что лучшая документация по XML — это спецификация языка, снабженная внятными аннотациями, комментариями и примерами. Первая глава описывает синтаксис и конструкции языка XML именно в том виде, в каком они приведены в технической рекомендации Консорциума W3, акцентируя внимание на важных с точки зрения XSLT моментах.

Помимо синтаксиса и физической модели ХМL-документа, в первой главе раскрывается концепция XML, идея, которая за всем этим стоит. Краткий обзор практических аспектов использования XML подкреплен описаниями архитектуры типовых проектов, основанных на XML-технологиях.

Завершающая часть первой главы посвящена истории языка XML.

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

Особое внимание уделяется практическому использованию XSLT в составе информационных систем. Во второй главе рассматриваются наиболее естественные области применения технологии XSLT.

Глава заканчивается краткой справкой об истории языка XSLT.

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

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

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

Шестая глава посвящена языку XPath, который используется в XSLT для выборок и вычислений на ХМL-документах. В этой главе рассматривается синтаксис и семантика XPath-выражений и паттернов XSLT и детально описываются функции базовой библиотеки XPath.

В этой главе описываются основные элементы XSLT — элементы, которые непосредственно создают части выходящего документа, вычисляют выражения, производят копирование, обеспечивают условную и циклическую обработку. Основные элементы предоставляют "базовый набор услуг", без которых, как правило, не обходится ни одно преобразование.

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

Эта глава поможет сделать первые шаги разработчикам, которым необходимо использовать XSLT совместно с другими языками программирования. В ней приведены простые примеры вызова преобразований из программ на таких языках программирования, как Object Pascal, C/C++, VBScript, JavaScript, Java и некоторых других.

Десятая глава посвящена вопросам создания и использования функций и элементов расширения. В этой главе разбирается процесс написания и подключения функций и элементов расширения на примере интерфейсов таких процессоров, как Saxon, Xalan и Oracle XSLT Processor, а также вопросы, связанные с обеспечением переносимости и отработкой исключительных ситуаций в преобразованиях, использующих расширения.

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

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

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

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

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

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

Несмотря на то, что эта книга главным образом посвящена языку XSLT, в ней также описываются расширяемый язык разметки XML и язык обращения к частям ХМL-документов, называемый XPath. Подробное и точное описание этих языков невозможно без четких определений синтаксических конструкций.

Для описания синтаксиса рассматриваемых языков мы будем использовать расширенные формы Бэкуса-Наура (РФБН, или, по-английски, Extended Backus-Naur Form, EBNF). EBNF — это современная модификация методологии, которая впервые была использована для описания языка программирования Алгол-60. За прошедшие десятилетия формы Бэкуса-Наура были доработаны множеством авторов и сейчас в расширенном виде используются для описания ряда языков программирования различной степени сложности. EBNF-нотация также широко используется в технических рекомендациях Консорциума W3, которые фактически и являются стандартами рассматриваемых нами языков.

Нотация EBNF определяет язык как набор синтаксических правил, определяющих нетерминалы (конструкции языка) через терминалы (символы языка), а также другие нетерминалы. Правило состоит из двух частей, разделенных символами "::=":

конструкция ::= определение конструкции

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

Терминалы, которые могут быть как отдельными символами, так и их последовательностями, определяются в нотации EBNF следующим образом:

□ #xN, где N — шестнадцатеричный код, соответствует символу Unicode с кодом N. Например, #х410 соответствует символу А кириллического алфавита (см. раздел "Использование Unicode" главы 1).

□ [a-zA-z], [#xN-#xN] — соответствует символу указанного интервала. К примеру, [a-f] соответствует любому из символов а, b, с, d, e, f.

□ [abc], [#xN#xN#xN] — соответствует любому из перечисленных символов. Например, [#х410#х411#х412] соответствует любому из символов А, Б, В. Символьные интервалы и перечисления могут использоваться совместно в одних квадратных скобках.

□ [^a-z], [^#хN-#xN] — соответствует любому символу, кроме символов указанного интервала. К примеру, [^#х410-#x42F] соответствует любому символу, кроме заглавных букв русского алфавита.

□ [^abc], [^#xN#xN#xN] — соответствует любому, кроме перечисленных символов. Например, [^xyz] соответствует любому символу, кроме символов x, y и z. Аналогично разрешенным интервалам и последовательностям символов, запрещенные интервалы и последовательности также могут использоваться совместно.

□ "строка" — соответствует строке, которая приведена в двойных кавычках. Например, "stylesheet" соответствует строке stylesheet.

□ 'строка' — соответствует строке, которая приведена в одинарных кавычках. Например, 'template' соответствует строке template.

Терминалы могут использоваться совместно с нетерминальными конструкциями в более сложных выражениях.

□ A? означает, что выражение A необязательно и может быть пропущено.

□ A | B соответствует либо выражению A, либо выражению B, но не им обоим одновременно (строгое "или"). Выражения такого вида называют иначе выбором.

□ A B означает, что за выражением A следует выражение B. Последовательность имеет приоритет по сравнению с выбором — A B | C D означает последовательность выражений A и B или последовательность выражений C и D.

□ A - B соответствует строке, которая соответствует выражению A, но не выражению B.

□ A+ означает последовательность из одного или более выражения A. Оператор "+" в EBNF старше оператора выбора, A+ | B+ означает последовательность из одного или более выражения A или последовательность из одного или более выражения B.

□ A* означает последовательность из нуля или более выражений A. Аналогично оператору "+", оператор "*" старше оператора выбора

□ (выражение) — круглые скобки используются для группировки выражений. Выражения, заключенные в скобки, рассматриваются, как отдельная единица, которая может быть свободно использована в приведенных выше конструкциях. Например, выражение A B C | B C | A D C | D C | C можно переписать в виде (A? (B | D) ) C.

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

Рассмотрим реальную продукцию Digits языка XPath. Digits — это последовательность из нескольких цифр от 0 до 9 и определяется она следующим образом:

Digits ::= [0-9] +

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

[31] Digits ::= [0-9]+

При помощи продукции Digits определяется такая продукция, как Number, которая соответствует числу. Число — это последовательность цифр, разделенная точкой на целую и дробную части:

[30] Number ::= Digits ('.' Digits?)?

                | '.' Digits

Чтобы лучше понять EBNF, попробуем немного упростить эту продукцию. Выражение Digits? внутри круглых скобок означает, что Digits может как присутствовать, так и быть опущенным, то есть ('.' Digits?) ? равносильно '.' ? | ('.' Digits)?. Повторяя еще раз подобное упрощение с каждым из полученных выражений, в итоге преобразуем правило Number к виду:

Number ::= Digits

           | Digits '.' Digits

           | Digits '.'

           | '.' Digits

Следовательно, число имеет четыре варианта синтаксиса:

□ последовательность цифр, например 12345;

□ последовательность цифр, разделенная точкой на целую и дробную части, например 3.14;

□ последовательность цифр, заканчивающаяся точкой, например 6. — что эквивалентно 6.0;

□ последовательность цифр, начинающаяся точкой, например .5, что эквивалентно 0.5.

Разберем еще одну продукцию языка XPath — определение литерала. Литерал в XPath — это последовательность символов, заключаемая в одинарные или двойные кавычки, которая используется в качестве строкового параметра в функциях и т.д. Единственным и вполне логичным ограничением на синтаксис литерала является то, что он не может содержать символ собственных кавычек — в этом случае непонятно, где же на самом деле литерал кончается, а где начинается (например, 'ab'cd').

Конструкция Literal задается следующим образом:

[29] Literal ::= '"' [^"]* '"'

                 | "'" [^']* "'"

В первом случае синтаксис литерала начинается двойными кавычками ('"'), затем идет последовательность, состоящая из любых символов, кроме двойных кавычек ([^"]*), затем закрывающие двойные кавычки ('"'). Во втором случае синтаксис имеет точно такой же вид с точностью до замены одинарных кавычек двойными и наоборот.

Другим очень часто используемым правилом является правило, определяющее пробельное пространство (англ. space или whitespace). Пробельными символами в XML-языках считаются такие символы, как табуляция, перевод строки, возврат каретки и сам пробел. Продукция S пробельного пространства задается, как последовательность из одного или более пробельного символа:

[3] S ::= (#х20 | #х9 | #xD | #хА)+

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

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

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

<!-- Текст входящего документа -->

Для того чтобы текст XML-документов был более наглядным, в листингах он будет форматироваться с пробельными отступами, например:

<foo bar="1">

 <FOO/>

</foo>

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

<?xml version="1.0" encoding="UTF-8"?><foo bar="1"><FOO></foo>

В тех случаях, когда позиции пробельных символов документа важны для повествования, они будут особым образом выделяться. Для обозначения пробела мы будем использовать символ "□", а для обозначения символа переноса строки — символ "¶", например:

<а xmlns:d="urn:d">¶

□□<d:b>¶

□□□□<с>¶

□□□□□□<e>¶

□□□□□□</e>¶

□□□□</с>¶

□□</d:b>¶

</а>

Базовые понятия или моменты, на которые следует обратить повышенное внимание, выделяются в тексте курсивом. Иностранные аббревиатуры и термины расшифровываются и переводятся в скобках, например: XSLT (от англ. extensible Stylesheet Language for Transformations — расширяемый язык стилей для преобразований). Ссылки на другие книги берутся в квадратные скобки с указанием года издания, например, [Кнут 2001]. Более точные библиографические данные можно найти в списке литературы.

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

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

Проблема понимания между человеком и машиной усугубляется еще и тем, что машина — это цифровое устройство, и все данные в ней состоят из атомов информации — битов, принимающих только два значения — "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 задан набор тегов для визуального форматирования документа, например:

□ <P>содержимое</P> — выделяет содержимое, как параграф;

□ <BR> — задает перенос строки;

□ <B>содержимое</B> — выделяет содержимое полужирным шрифтом;

□ <I>содержимое</I> — выделяет содержимое курсивом;

□ <U>содержимое</U> — подчеркивает содержимое.

Теги могут быть парными и одиночными. Парные теги (например, <B>содержимое</B>) выделяют часть документа, одиночные (например, <BR>) задают некую инструкцию.

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

<Р>Предлагаем Вашему вниманию новый 3-х камерный холодильник <В>"Горск"</В> объемом 250 л. и стоимостью всего <В>4500</В> рублей! Новый дизайн, <I>быстрое охлаждение</I> и <I>низкое энергопотребление</I>, <В>3-х годовая гарантия</В> на все узлы и агрегаты, а также <I>бесплатная доставка по городу</I>! Заказывайте прямо сейчас по телефону <U>091-12- 15<U>. <BR><BR>Фирма "Горск-Холод".</Р>

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

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

<advert>

 Предлагаем Вашему вниманию новый <room>3</room>-x камерный

 <product>холодильник</product> <product-title>"Горск"</product-title>

 объемом <volume>250 л.</volume> и стоимостью всего <price>4500</price>

 рублей!

 Новый дизайн, <feature>быстрое охлаждение</feature> и

 <feature>низкое энергопотребление</feature>,

 <guarantee>3-x годовая гарантия</guarantee> на все узлы и агрегаты, а

 также <service>бесплатная доставка по городу</service>!

 <order>

  Заказывайте прямо сейчас по телефону <phone>0-91-12-15</phone>.

 </order>

 <company>Фирма "Горск-Холод".</company>

</advert>

В таком виде этот документ содержит гораздо более подробную информацию о своей структуре: внутри тега <product-title> указано наименование продукта, внутри тега <price> — цена, внутри тега <service> — какой сервис предоставляет фирма и так далее. Такой текст уже можно обработать программно. Если понадобится составить таблицу, содержащую названия холодильников, объем, цену, название фирмы и телефон, все, что потребуется сделать — это получить содержимое тегов <product-title>, <volume>, <price>, <company> и <phone>. При этом совершенно не теряется возможность визуального представления документа: нужно лишь определить, как будет выглядеть содержимое того или иного тега.

Таким образом, просто расширив множество тегов, мы убили сразу двух зайцев.

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

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

В этих двух положениях и есть смысл XML (англ. extensible Mark-up Language, расширяемый язык разметки) — отделять данные от представления и создавать в текстовом виде документы со структурой, указанной явным образом.

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

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

Для того чтобы познакомиться с устройством XML-документов, рассмотрим простой пример:

<?xml version="1.0"?>

<advert>

 <product title="Слон">

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

 </product>

</advert>

Первая строка документа определяет его как XML-документ, построенный в соответствии с первой версией языка. Следующая строка содержит открывающий тег <advert>. Далее находится открывающий тег <product>, который имеет атрибут title со значением "Слон". Четвертая строка в документе — рекламный лозунг "Покупайте наших слонов!". Затем следует закрывающий тег </product> и, наконец, закрывающий тег </advert>.

XML использует ту же теговую разметку, что и HTML, но при этом теги в XML не просто ограничивают часть текста документа — они выделяют в документе один элемент. В предыдущем примере документ имел два элемента — advert:

<advert>

 <product title="Слон">

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

 </product>

</advert>

и product:

<product title="Слон">

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

</product>

Как видно, элемент product включен в элемент advert. Точно так же, как в HTML одни теги могли находиться внутри других тегов, в XML элементы могут содержать другие элементы, а также иметь атрибуты и содержать текст. В следующем разделе мы подробно рассмотрим основные конструкции 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). Это означает, что при определении значений сущностей и атрибутов можно использовать ссылки на сущности, например, в элементе заданном как:

<song title="Крейсер &quot;Aвpopa&quot; "/>

атрибут title имеет значение крейсер "Аврора". Двойные кавычки были определены посредством встроенных сущностей.

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

[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

Теперь, когда мы разобрали практически все структурные единицы 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, это далеко не панацея и не решение всех проблем, которые могут возникнуть. Нужно хорошо понимать, что XML — это всего лишь формат описания данных. Четкий, конкретный, независимый, мощный формат описания данных — но не более! XML-технологии могут решить проблемы представления, несоответствия синтаксиса семантике и многие другие проблемы организации данных в документе, но они не смогут решить чисто программистских задач — как обрабатывать эти документы. XML не имеет особого смысла вне прикладных задач.

В качестве типичного примера можно привести язык XSLT (язык расширяемых стилей для преобразований, extensible Stylesheet Language for Transformations), который находится в фокусе этой книги. Программы, написанные на XSLT, называются преобразованиями, и они являются в прямом смысле XML-документами, но при этом удовлетворяют логической схеме языка XSLT. При этом преобразования не имели бы смысла без XSLT-процессора, который может применять их к другим документам. Они были бы просто текстом.

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

Стандартизированный и совсем не сложный синтаксис XML позволил многим компаниям разработать средства для синтаксического разбора XML-документов. Программы такого рода называют XML-парсерами (англ. parse — разбирать, анализировать). В настоящее время существует два основных типа XML-парсеров: SAX-парсеры и DOM-парсеры. Оба типа широко используются в различных приложениях — парсеры избавляют от необходимости писать собственные синтаксические анализаторы, штудировать спецификации и так далее. Мы коротко опишем каждый из этих типов.

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

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

Как уже было упомянуто абзацем выше, легкие SAX-парсеры не создают внутреннего представления ХМL-документов, вполне справедливо считая, что этим придется заняться программисту.

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

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

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

При выборе парсера необходимо хорошо понимать задачи, которые нужно будет решать при обработке документа. Во многих случаях совершенно необязательно целиком представлять документ в памяти. Будет вполне достаточным создать обработчик документа, и затем, при помощи SAX-парсера, произвести обработку без особых затрат ресурсов. Если же, напротив, при обработке важно иметь модель всего документа целиком, лучше использовать готовое решение в виде DOM-парсера.

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

□ обращение к преобразуемому объекту;

□ создание результата преобразования;

□ логика, связывающая первые два действия и направляющая процесс преобразования.

Применительно к преобразованию XML-документов первая подзадача означает получение информации, которую этот документ содержит — в том числе и информации о структуре, которая является неотъемлемой его частью. Обращение в данном случае имеет несколько смыслов, в том числе — опрашивать, делать запросы, вычислять, выбирать; в общем смысле — задавать о документе вопросы и получать на них ответы. Для этой цели в XSLT служит язык, называемый XPath — язык путей в ХМL-документах (от англ. XML Path Language). Как мы увидим, XPath является лаконичным, но при этом чрезвычайно мощным средством обращения к XML-документам (а также к их частям). Роль XPath в XSLT так велика, что их можно было бы считать единым целым, если бы только XPath не использовался также и в других языках, предназначенных для работы с XML.

Вторая и третья условные части преобразования являются прерогативой самого XSLT. XSLT — это XML-язык в полном смысле этого слова: программы на XSLT (мы будем называть их преобразованиями сообразно их предназначению) являются хорошо оформленными (well-formed) XML-документами. XSLT также использует пространства имен; практически все имена, встречающиеся в XSLT, как-то: имена переменных, шаблонов, форматов и так далее — рассматриваются как расширенные имена, характеризуемые локальной частью вкупе с URI — уникальным идентификатором пространства имен.

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

В качестве первого примера XSLT-преобразования, который будет приведен в этой книге, мы рассмотрим классическую программу "Hello, world!". Листинг 2.1 показывает XSLT-интерпретацию "Hello, world!", когда мы преобразуем документ

<msg>Hello, world!</msg>

в документ вида:

<message>Hello, world!</message>

<xsl:stylesheet

 version="1.0"

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

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

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

f(x, у) > вернуть x + у;

будет чистой функцией. Сколько бы раз мы ее не вызывали, ее результат все равно будет равен сумме аргументов. Кроме того, результат вычисления f(f(x₁, y₁), f(x₂, y₂)) будет равен x₁ + y₁ + x₂ + y₂, в каком бы порядке мы не вычисляли эти функции:

f(f(x₁, y₁), f(x₂, y₂)) = f(x₁ + y₁, f(x₂, y₂)) = x₁ + y₁ + f(x₂, y₂) = x₁ + y₁ + x₂ + y₂

f(f(x₁, y₁), f(x₂, y₂)) = f(f(x₁, y₁), x₂ + y₂) = f(x₁, y₁) + x₂ + y₂ = x₁ + y₁ + x₂ + y₂

f(f(x₁, y₁), f(x₂, y₂)) = f(x₁, y₁) + f(x₂, y₂) = x₁ + y₁ + f(x₂, y₂) = x₁ + y₁ + x₂ + y₂

и так далее.

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

f(x, у) → z присвоить x; увеличить z на у; вернуть z;

В данном случае побочный эффект состоит в изменении значения переменной z. В этом случае результат вычисления выражения f(z, f(x, у)) строго зависит от того, в каком порядке будут вычисляться функции — в одних случаях результатом будет x + у + z, в других 2∙x + 2∙у. Для того чтобы результат вычислений с побочными эффектами был детерминирован, требуется строгая определенность в порядке действий. В XSLT же эта строгая определенность отсутствует, преобразование — это набор правил, а не последовательность действий.

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

Сильнее всего это ограничение сказывается на стиле XSLT-программирования. Он становится ближе к функциональному стилю таких языков, как Lisp и Prolog. Научиться соответствовать этому стилю просто, хотя поначалу он и будет казаться неудобным.

Слово extensible (англ. расширяемый) в расшифровке аббревиатуры XSLT исторически происходит из названия языка XSL, но оно вполне применимо и к самому XSLT: спецификация этого языка позволяет разрабатывать собственные функции и элементы и использовать их в преобразованиях.

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

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

Технология расширений делает XSLT поистине универсальным языком, ведь получается, что в нем можно использовать любые вычисления, которые только могут быть описаны в классических языках программирования.

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

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

Естественно, XSLT имеет также и некоторые ограничения:

□ XSLT не подходит для описания преобразований с очень сложной логикой;

□ XSLT не подходит для преобразований, которые требуют сложных вычислений.

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

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

Ниже мы опишем наиболее классические области применения XSLT: Web-решения, использование в клиент-серверных приложениях и проекты интеграции.

Попытаемся теперь взглянуть на приложения архитектуры клиент-сервер под несколько иным углом и в более узкой области Web-решений.

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

□ клиент запрашивает определенный документ;

□ сервер находит (или генерирует) этот документ;

□ сервер находит (или генерирует) преобразование, ассоциированное с этим документом, и применяет его к документу;

□ результат преобразования возвращается клиенту (например, в виде HTML-файла).

В подобной системе можно выделить три базовых компонента (рис. 2.7):

□ генератор — модуль, который создает документ на основе информации, хранящейся в базе данных или просто в файлах на сервере;

□ процессор преобразований — модуль, который применяет преобразования к сгенерированному документу;

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

Рис. 2.7. Декомпозиция системы Web-публикации

В таком виде XSLT создает сильную конкуренцию серверным скриптовым языкам типа ASP, JSP, PHP, Python и так далее. Web-системы, построенные на XML и XSLT, гораздо гибче и легче в реализации, а их масштабируемость нельзя даже сравнивать. В традиционных системах добавление еще одного представления данных (например, текстовой версии документа или версии "для печати") — это еще одна программа на сервере, в то время как в системах, использующих XSLT, — это всего лишь еще одно преобразование (рис. 2.8).

Рис. 2.8. Создание множественных представлений с использованием XSLT

XSLT является одной из основных технологий систем Web-публикации, как Cocoon от Apache XML Project и XSQL от Oracle. Решения на основе. Cocoon и XSQL отличаются мощностью, гибкостью и простотой; ожидается, что системы этого класса займут в скором времени лидирующие позиции.

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

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

Действительно, предположим, что наши приложения уже имеют определенный XML-интерфейс (рис. 2.9):

Рис. 2.9. Приложение с XML-интерфейсом

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

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

Рис. 2.10. Интеграция приложения с XML-интерфейсом в общую схему

Упомянутая выше задача перевода, или, по-другому, преобразования, есть очевидная область применения языка XSLT. Общая схема интеграции на основе XML и XSLT показана на рис. 2.11.

Рис. 2.11. Схема интеграции приложений на основе XML/XSLT

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

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

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

<а>

 <b/>

 <с/>

</а>

может быть представлен деревом (рис. 3.1).

Рис. 3.1. Представление документа в виде дерева

Аналогия совершенно очевидна — элемент а содержит элементы b и с, в то время как в дереве вершина а является родительским узлом для вершин b и с.

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

□ корневой узел;

□ узлы элементов;

□ узлы атрибутов;

□ текстовые узлы;

□ узлы пространств имен;

□ узлы инструкций по обработке;

□ узлы комментариев.

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

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

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

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

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

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

Формально [Кнут 2000] дерево определяется, как конечное множество T, состоящее из одного или нескольких элементов (узлов), обладающих следующими свойствами:

□ во множестве T выделяется единственный узел, называемый корневым узлом или корнем;

□ все остальные узлы разделены на m≥0 непересекающихся множеств T₁, …, T_m, каждое из которых в свою очередь также является деревом.

Деревья T₁, …, T_m называются поддеревьями корня дерева T.

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

В XSLT и XPath деревья являются упорядоченными, то есть для множеств T₁, …, T_m задается порядок следования, который называется порядком просмотра документа. В XSLT деревья упорядочиваются в порядке появления текстового представления их узлов в документах.

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

Рис. 3.2. Изображение дерева

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

□ Дочерним узлом текущего узла называется любой из корней его поддеревьев. Например, в дереве на рис. 3.2 дочерними узлами узла а являются узлы b и с, а дочерними узлами узла b — узлы d и e. Узел с не имеет дочерних узлов — такие узлы иначе называются листьями.

□ Каждый узел называется родительским узлом корней своих поддеревьев. На рис. 3.2 узел а является родителем узлов b и с, а узел b — родителем узлов d и e.

□ Корни поддеревьев называются братскими узлами или узлами-братьями. На рис. 3.2 братьями являются узлы b и с, а также узлы d и e.

□ Предками текущего узла являются его родитель, а также родители его родителей и так далее. На рис. 3.2 предками узла d являются узлы b и а.

□ Потомками текущего узла являются его дочерние узлы, а также дочерние узлы его дочерних узлов и так далее. На рис. 3.2 потомками узла а являются узлы b, c, d и e.

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

□ Не учитывается информация, содержащаяся в блоке DTD. Как следствие, в XSLT невозможно манипулировать определениями сущностей, элементов, атрибутов и так далее.

□ Не учитываются некоторые синтаксические особенности входящего XML-документа. Например: использовались ли в определенном атрибуте одинарные или двойные кавычки; была ли определенная строка задана сущностью или просто текстом, был ли текст заключен в секции CDATA или нет.

□ Если атрибут элемента был определен в DTD со значением по умолчанию, то в преобразовании нельзя точно сказать, присутствовал ли он физически во входящем документе или нет.

□ Не учитывается, был ли пустой элемент определен как <b></b> или <b/>.

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

Узлы дерева XML-документа находятся в определенном порядке, который называется порядком просмотра документа (англ. document order). Этот порядок важен для вычисления XPath-вырэжений, которые оперируют множествами узлов. Несмотря на то, что эти множества не имеют внутреннего порядка, при вычислении выражений узлы в них будут перебираться в прямом или обратном порядке просмотра документа в зависимости от того, какие оси навигации применяются в выражении.

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

Более четко порядок просмотра документа определяется следующими правилами:

□ корневой узел является первым узлом в порядке просмотра документа;

□ узлы элементов предшествуют своим дочерним узлам, узлам пространств имен и узлам атрибутов;

□ узлы пространств имен предшествуют узлам атрибутов;

□ узлы атрибутов предшествуют другим дочерним узлам своего элемента;

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

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

В качестве примера приведем схему дерева и выясним порядок просмотра

следующего документа:

<!-- Start -->

<?арр open?>

<а level="0" xmlns:b="urn:b" xmlns="urn:a">

 alpha

 <b:bravo/><!-- To do... --><charlie/>

 delta

</a>

<?app close?>

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

□ корневой узел;

□ узел комментария <!-- start -->;

□ узел инструкции по обработке <?app open?>;

□ узел элемента a;

□ узел пространства имен "urn:а";

□ узел пространства имен "urn:b";

□ атрибут level;

□ текстовый узел "alpha";

□ узел элемента b:bravo;

□ узел пространства имен "urn:а";

□ узел пространства имен "urn:b";

□ комментарий с текстом "To do ...";

□ элемент charlie;

□ узел пространства имен "urn:а";

□ узел пространства имен "urn:b";

□ текстовый узел "delta";

□ узел инструкции по обработке <?арр close?>.

Рис. 3.11. Схема дерева XML-документа

Соответственно, обратный порядок просмотра документа будет начинаться с инструкции по обработке <?app close?> и заканчиваться корневым элементом.

Многие языки программирования при объявлении переменной требуют указывать, какой тип данных будет ей присваиваться. Например, в языке Java код

int i = 15;

объявит переменную целого типа int с именем i и присвоит ей значение 15. В этом случае тип данных ставится в соответствие переменной. XSLT относится к динамически типизируемым языкам, в которых тип данных ассоциируется не с переменными, а со значениями.

В XSLT выделяется пять типов данных:

□ булевый тип (boolean);

□ численный тип (number);

□ строковый тип (string);

□ множество узлов (node-set);

□ результирующий фрагмент дерева (result tree fragment).

Ниже мы подробно рассмотрим особенности работы со всеми пятью типами данных.

Булевый тип данных в XSLT может принимать два значения — true ("истина") и false ("ложь"). В XSLT нет констант для выражения тождественной "истины" или "лжи", как во многих других языках программирования, для этих целей следует использовать функции true и false.

Значение булевого типа могут быть получены путем сравнения других типов данных при помощи операторов сравнения (таких как "=", ">", "<") или как результат вычисления более сложных логических выражений с использованием операторов "and", "or" и функции not.

Булевый тип может быть неявно преобразован в число (0 для false и 1 для true) или в строку ("false" и "true" соответственно).

Примеры:

1=2 → 0 (число)

not((2>1) and (2>3)) → "true" (строка)

Численный тип в XSLT определяется как 64-битное значение с плавающей точкой, двойной точности, соответствующее стандарту IEEE 754-1985. Этот стандарт используется во многих других языках программирования, и потому можно сказать, что арифметика в XSLT работает "как обычно". Вместе с тем, стандарт IEEE 754 имеет свои нюансы, которые обязательно надо учитывать в практике программирования на XSLT.

Согласно строгому определению, числа в XSLT имеют форму s×m×2^x, где s — знак числа, m — его мантисса, а x — экспонента. Эти числа имеют следующие значения:

□ знак (s) равен +1 для положительных чисел и -1 для отрицательных;

□ мантисса (m) — это положительное целое число в интервале от 0 до 253-1 включительно;

□ экспонента (x) — это целое число в интервале от -1075 до 970 включительно.

Таким образом, числа в XSLT находятся в интервале приблизительно от -10317 до 10317.

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

□ Отрицательная бесконечность. Это значение представляет отрицательные числа, меньшие, чем -10317; оно соответствует математическому значению -∞. Отрицательная бесконечность может быть результатом таких операций, как деление отрицательного числа на нуль или умножение двух очень больших (в абсолютном значении) чисел разного знака в случае, когда для записи их произведения не хватит 64 бит.

□ Положительная бесконечность. Это значение представляет очень большие положительные числа, превосходящие 10317; оно соответствует математическому значению ∞. Положительная бесконечность может быть результатом таких операций, как деление положительного числа на нуль или умножение двух очень больших (в абсолютном значении) чисел одного знака в случае, когда для записи их произведения не хватит 64 бит.

□ Отрицательный нуль. Это значение соответствует значению предела -1/x при x, стремящемся к бесконечности. Отрицательный нуль может быть результатом таких операций, как деление отрицательного числа на бесконечность или положительного числа на отрицательную бесконечность. Отрицательный нуль может также быть получен путем деления отрицательного числа на очень большое положительное число, или, наоборот, в случае, когда для записи частного не хватает 64-битной точности.

□ Положительный нуль (предел 1/x при x, стремящемся к бесконечности). Результат таких операций, как вычитание числа из самого себя, деление положительного числа на положительную бесконечность или отрицательного — на отрицательную бесконечность. Положительный нуль может также быть частным деления двух чисел одного знака, если для записи результата не хватает 64-битной точности.

□ Особое значение NaN, "не-число" (англ. "not-a-number"). Результат преобразования нечислового строкового значения в числовой формат.

Примеры особых значений:

-1 div 0 → отрицательная бесконечность

1 div 0 → положительная бесконечность

1 div (-1 div 0) → отрицательный нуль

-1 div (1 div 0) → отрицательный нуль

1 div (1 div 0) → положительный нуль

-1 div (-1 div 0) → положительный нуль

1-1 → положительный нуль

number('one') → NaN, не-число

number('NaN') → NaN, не-число

Все числовые значения, кроме NaN являются упорядоченными, иначе говоря, для них определены операции сравнения.

□ Отрицательная бесконечность является наименьшим численным значением. Две отрицательные бесконечности равны между собой.

□ Отрицательные конечные числа больше отрицательной бесконечности, но меньше отрицательного нуля.

□ Отрицательный и положительный нули считаются равными.

□ Положительные конечные числа больше положительного нуля, но меньше положительной бесконечности.

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

□ 1 div (1 div 0) < 1 div 0 → true

(положительный нуль меньше положительной бесконечности);

□ 1 div 0 < 2 div 0 → false

(положительный нуль равен другому положительному нулю);

□ -2 div 0 > -1 div 0 > false -1 div 0 = -2 div 0 → true

(отрицательные бесконечности равны между собой);

□ -1 div 0 < -1 → true

(отрицательная бесконечность меньше любого отрицательного числа);

□ -1 < -2 div (1 div 0) → true

(любое отрицательное число меньше отрицательного нуля);

□ -2 div (1 div 0) = 1-1 → true

1 div (1 div 0) > -2 div (1 div 0) → false

(отрицательный нуль равен положительному нулю);

□ 1 > 1 div (1 div 0) → true

(любое положительное число превосходит положительный нуль).

Нечисловые значения, NaN, являются неупорядоченными — это означает, что, сравнивая их с другими числами, нельзя установить — больше они, меньше или равны. Результат сравнений операторами "<", "<=", "=", ">", ">=" будет "ложью", если хотя бы одно из сравниваемых значений — NaN. Единственное, что можно с точностью сказать о NaN — это то, что они не равны никакому другому числу, включая, собственно, нечисловые значения. То есть, если хотя бы один из операндов — NaN, результатом сравнения с использованием оператора "!=" будет "истина". Это влечет за собой интересный способ проверки, является ли значение некоторой переменной нечисловым или нет: выражение $x!=$x (буквально значение переменной x не равно значению переменной x) обратится в "истину" в том и только том случае, если значением $x является NaN. В шаблонных правилах эта проверка может быть записана при помощи элемента xsl:if:

<xsl:if test="$x != $x">

 <xsl:text>This is not a number (NaN).</xsl:text>

</xsl:if>

Арифметические операции в XSLT никогда не вызывают ошибки. Деление на нуль, не разрешенное во многих языках программирования, не является для XSLT исключительной ситуацией. Частным такого деления будет положительная или отрицательная бесконечность. Но все же, следует осторожно использовать "опасные" выражения, например, в сравнениях. Несколько необычное поведение операторов сравнения в операциях с NaN может создать в программе курьезные, но трудно обнаруживаемые ошибки — можно легко забыть о том, что некоторые значения могут быть не равны сами себе.

Числа могут быть неявно преобразованы в булевый тип или в строку. При преобразовании числа в булевый тип, нуль (как положительный, так и отрицательный) и NaN преобразуются в false, все остальные значения (включая бесконечности) — в true.

-1 div (1 div 0) > false 1 div 0 → true

number('NaN') > false number('true') → false

Результатом неявного преобразования числа в строку является:

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

□ для нулей (и положительного, и отрицательного) — "0";

□ для бесконечностей (отрицательной и положительной) — "-Infinity" и "Infinity" соответственно;

□ для нечисловых значений — "NaN".

-14 div 3 → '-4.666666666666667'

0010.00050000 → '10.0005'

-1 div (1 div 0) → '0'

1 - 1 → '0'

1 div 0 → 'Infinity'

-2 div 0 → '-Infinity'

number('NaN') → 'NaN'

number('Infinity') → 'NaN'

Кроме неявного преобразования в строку, XSLT предоставляет широкие возможности для форматирования числовых значений с использованием функции format-number.

Строки в XSLT практически не отличаются от строк в других языках программирования. Строка — это последовательность, состоящая из нуля или более символов определенного алфавита или набора символов (англ. character set). XSLT использует в качестве алфавита Unicode, что теоретически позволяет манипулировать любыми символами. Строки, которые не содержат символов, называются пустыми.

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

Результатом выполнения элемента

<xsl:value-of select="'text'"/>

будет строковый узел со значением "text", в то время как элемент

<xsl:value-of select="text"/>

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

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

<xsl:variable name="s">

 <xsl:text>'An author of "One Flew Over Cookoo's Nest"'</xsl:text>

</xsl:variable>

<xsl:value-of select="$s"/>

Следует особым образом отметить, что в XSLT, как XML-языке, символы могут быть заменены сущностями. Например, вместо символа """ (двойные кавычки) можно использовать сущность ", а вместо символа "'" (одинарные кавычки) — '. Это позволяет использовать внутри атрибутов такие конструкции, как

'this is a string'

что эквивалентно

'this is a string'

На практике следует избегать таких приемов — они сильно запутывают текст программы. Сущности следует использовать только тогда, когда это действительно необходимо.

Строки можно сравнивать при помощи операторов "=" (равно) или "!=" (не равно). При сравнении строки проверяются на посимвольное совпадение. Различные процессоры могут по-разному реализовывать процедуру сравнения, например, рассматривать разные символы с одним начертанием как одинаковые, но в одном можно быть точно уверенными — в случае, если на одних и тех же местах будут стоять символы с одинаковыми Unicode-кодами, строки будут равны.

'not' = 'no&#х74;' → true

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

Строка может быть приведена к булевому и численному типу.

В булевом представлении пустой строке соответствует false, непустой — true. Содержимое непустой строки при этом никакой роли не играет. Булевое значение строки "false" будет "истиной", равно, как и булевое значение строки "true".

'То be' or 'not to be' → true

'Full' and '' → false

'true' and 'false' → true

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

'2' * '2' → 4

'one' + 'two' → NaN

'2/3' + '5/6' → NaN

'2' div '3' + '5' div '6' → 1.5

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

□ -, унарный оператор, который выполняет отрицание своего единственного операнда — эта операция равносильна вычитанию числа из нуля;

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

□ -, бинарный оператор вычитания, возвращает разность своих операндов;

□ *, бинарный оператор умножения, возвращает произведение своих операндов;

□ div, бинарный оператор деления, возвращает частное от деления первого операнда на второй;

□ mod, бинарный оператор, возвращающий остаток от деления первого операнда на второй.

Обратим внимание на то, что оператор div в отличие от его трактовки в языке Pascal, выполняет нецелое деление. Результатом вычисления выражения 3 div 2 будет 1.5, а не 1.

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

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

Множество узлов — это чистое математическое множество, состоящее из узлов дерева: оно не содержит повторений и не имеет внутреннего порядка элементов. Множества узлов выбираются особым видом XPath-выражений, которые называются путями выборки (англ. location path).

<А>

 <В/>

 <С>

  <D>

   <G/>

  </D>

  <E/>

  <F>

   <H/>

   <I/>

  </F>

 </C>

</A>

Предположим, что в этом документе мы хотим выбрать все узлы, являющиеся потомками элемента C, который находился бы в элементе A, который находится в корне документа. Соответствующее XPath-выражение будет записано в виде /A/C//node().

Для наглядности представим наш документ в виде дерева (рис. 3.12) и выделим в нем соответствующее множество узлов.

Рис. 3.12. Выбор множества узлов

Выбранное множество состоит из узлов элементов D, G, E, F, H, I (рис. 3.13):

Рис. 3.13. Выбранное множество

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

В общем случае, во множество узлов не входят дети узлов, содержащихся в нем. В нашем примере узлы элементов G, H и I вошли в выбранное множество только потому, что они соответствовали пути выборки /A/C//node(). Если бы путь выборки имел вид /A/C/node() (то есть, выбрать всех детей узла C, содержащегося в узле A, находящемся в корне документа), результат (рис. 3.14) был бы иным.

Рис. 3.14. Другой путь выборки

Выбранное множество узлов имело бы вид (рис. 3.15):

Рис. 3.15. Выбранное множество

Для представления одного узла дерева в XSLT используется множество, состоящее из единственного узла. В предыдущем примере результатом выборки /A (выбрать узел A, находящийся в корне документа) было бы множество, состоящее из единственного узла (рис. 3.16).

Четыре типа данных, описанных выше, заимствованы языком XSLT из XPath. Вместе с тем, XSLT имеет и свой собственный тип данных, называемый result tree fragment (результирующий фрагмент дерева).

Для того чтобы понять этот тип данных, обратимся к примеру шаблона:

<xsl:template match="href">

 <B>You may visit the <A HREF="{location}">following link</A>.</B>

</xsl:template>

Если мы применим это правило к части документа

<href>

 <location>http://www.xsltdev.ru</location>

</href>

то получим следующий результат:

<B>You may visit the <A HREF="http://www.xsltdev.ru">following link</A>.</B>

В терминах деревьев выполнение этого шаблона показано на рис. 3.17.

Рис. 3.17. Часть дерева входящего документа и часть дерева сгенерированного документа

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

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

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

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

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

<href>

 <location>http://www.xsltdev.ru</location>

</href>

<xsl:stylesheet

 version="1.0"

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

 <xsl:variable name="href">

  <body>

   <xsl:apply-templates select="href"/>

  </body>

 </xsl:variable>

 <xsl:template match="href">

  <B>You may visit the <A HREF="{location}">following link</A>.</B>

 </xsl:template>

 <xsl:template match="/">

  <result>

   <xsl:text>&#xA;Result as string:&#xA;</xsl:text>

   <xsl:value-of select="$href"/>

   <xsl:text>&#xA;Result as tree:&#xA;</xsl:text>

   <xsl:copy-of select="$href"/>

   <xsl:text>&#xA;</xsl:text>

  </result>

 </xsl:template>

</xsl:stylesheet>

Листинг 3.12. Выходящий документ

<result>

 Result as string:

 You may visit the following link.

 Result as tree:

 <body><B>You may visit the <A HREF="http://www.xsltdev.ru">following

  link</A>.</B>

 </body>

</result>

Это преобразование легко понять, если обратиться к рис. 3.18.

Рис. 3.18. Генерация выходящего дерева с использованием переменных

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

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

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

При преобразовании дерева в строку результатом является конкатенация (строковое сложение) всех текстовых узлов дерева в порядке просмотра.

Пример

Результирующий фрагмент дерева

<body>

<B>You may visit the <A HREF="http://www.xsltdev.ru">following

link</A>.</B>

</body>

приводится к строке

The result is: You may visit the following link.

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

Пример Листинг 3.13. Входящий документ:

<numbers>

 <integer>1</integer>

 <real>1</real>

 <integer>2</integer>

 <real>2</real>

 <integer>3</integer>

 <real>3.5</real>

</numbers>

Листинг 3.14. Преобразование:

<xsl:stylesheet

 version="1.0"

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

 <xsl:variable name="integers">

  <integers><xsl:copy-of select="/numbers/integer"/></integers>

 </xsl:variable>

 <xsl:variable name="reals">

  <reals><xsl:copy-of select="/numbers/real"/></reals>

 </xsl:variable>

 <xsl:template match="/">

  <result>

   <xsl:text>&#xA; Integers:&#xA;</xsl:text>

   <xsl:value-of select="$integers"/>

   <xsl:text>&#xA;Reals:&#xA;</xsl:text>

   <xsl:value-of select="$reals"/>

   <xsl:text>&#xA;Reals minus integers:&#xA;</xsl:text>

   <xsl:value-of select="$reals - $integers"/>

   <xsl:text>&#xA;</xsl:text>

  </result>

 </xsl:template>

</xsl:stylesheet>

Листинг 3.15. Результат

<result>

Integers:

123

Reals:

123.5

Reals minus integers:

0.5

</result>

Для удобства использования все взаимные преобразования типов сведены в одну таблицу (табл. 3.2).

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

Можно выделить четыре основные задачи, для которых в преобразованиях используются выражения:

□ выбор узлов для обработки;

□ описание условий;

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

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

Первая из задач непосредственно относится к самому процессу преобразования. Выражения, содержащиеся в атрибутах select элементов xsl:apply-templates и xsl:for-each, вычисляют множества, к узлам которых нужно применить шаблоны.

<xsl:template match="HTML">

 <html>

  <xsl:apply-templates select="HEAD"/>

  <xsl:apply-templates select="BODY"/>

 </html>

</xsl:template>

В этом шаблонном правиле содержатся два элемента xsl:apply-templates, которые применяют шаблоны к множествам, выбранным выражениями HEAD и BODY соответственно.

Логические выражения XPath могут использоваться в качестве условий в таких элементах, как xsl:if и xsl:when, обеспечивая условную обработку.

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

<person>

 <name>Johnny</name>

 <age>19</age>

</person>

<xsl:stylesheet

 version="1.0"

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

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

Контекст преобразования состоит из узла, называемого контекстным узлом, двух целых чисел — размера контекста и позиции в контексте, объявлений переменных, объявлений пространств имен и библиотеки функций.

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

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

<element

 name="имя элемента"

 context-position="позиция в контексте"

 context-size="размер контекста"

 string-value="строковое значение">

 ...

</element>

<xsl:stylesheet

 version="1.0"

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

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

При выполнении преобразования каждая из его инструкций, каждый из элементов обрабатывается в некотором контексте. Контекст преобразования состоит из двух частей: из текущего множества узлов и из текущего узла, которые показывают, что именно обрабатывается в данный момент. XSLT-процессор поочередно обрабатывает каждый из узлов текущего множества (при этом делая этот узел текущим узлом) и объединяет результаты в одно дерево.

Контекст преобразования тесно связан с контекстом вычисления выражений:

□ текущий узел контекста преобразования соответствует контекстному узлу вычисления выражений;

□ позиция текущего узла в текущем обрабатываемом множестве соответствует позиции контекста вычисления выражений;

□ размер текущего множества узлов соответствует размеру контекста вычисления выражений.

Контекст преобразования может изменяться только двумя элементами — xsl:apply-templates и xsl:for-each. Каждый из этих элементов вычисляет множество узлов, которое становится текущим и затем обрабатывается. После этого контекст преобразования восстанавливается до того состояния, каким он был перед обработкой.

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

<summer>

 <month>June</month>

 <month>July</month>

 <month>August</month>

</summer>

Этому документу соответствует следующее дерево (рис. 3.19):

Рис. 3.19. Дерево входящего документа

<xsl:stylesheet

 version="1.0"

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

 <xsl:template match="/">

  <html>

   <head>

    <title>Summer</title>

   </head>

   <body>

    <xsl:apply-templates select="summer"/>

   </body>

  </html>

 </xsl:template>

 <xsl:template match="summer">

  <table>

   <tr>

    <xsl:apply-templates select="month"/>

   </tr>

  </table>

 </xsl:template>

 <xsl:template match="month">

  <td>

   <xsl:value-of select="."/>

  </td>

 </xsl:template>

</xsl:stylesheet>

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

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

<xsl:template match="/">

 <html>

  <head>

   <title>Summer</title>

  </head>

  <body>

   <xsl:apply-templates select="summer"/>

  </body>

 </html>

</xsl:template>

Тело этого шаблона выполняется в том самом изначальном контексте, о котором мы только что упомянули: текущее множество состоит из корневого узла, он же является и текущим узлом. Мы можем показать контекст, выделяя текущее множество, пунктиром, а текущий узел — полужирной линией (рис. 3.20).

Рис. 3.20. Первоначальный контекст преобразования

Атрибут select элемента xsl:apply-templates задает выражение, вычисляющее множество узлов, которые должны быть обработаны. Выражение summer, которое содержит этот атрибут, является относительным путем выборки, который возвращает все дочерние элементы summer текущего узла. Поскольку текущим узлом в данном контексте является корневой узел дерева, значением выражения summer будет множество узлов, состоящее из субэлемента summer, корневого узла.

При выполнении элемента xsl:apply-templates процессор сделает это вычисленное множество узлов текущим множеством и начнет поочередно обрабатывать его узлы, делая их при этом текущими. Иначе говоря, выполнение элемента

<xsl:apply-templates select="summer"/>

сведется к выполнению шаблона, обрабатывающего элемент summer. Этот шаблон выглядит следующим образом:

<xsl:template match="summer">

 <table>

  <tr>

   <xsl:apply-templates select="month"/>

  </tr>

 </table>

</xsl:template>

Выполняться он будет в следующем контексте (рис. 3.21):

Рис. 3.21. Контекст шаблона элемента summer

Атрибут select элемента xsl:apply-templates, который присутствует в этом шаблоне, вычисляет новое текущее множество: путь выборки month возвращает все дочерние элементы month текущего узла. Текущим узлом является элемент summer, то есть новое текущее множество будет состоять из трех его дочерних элементов month. Таким образом, процессор будет поочередно выполнять шаблоны в каждом из трех следующих контекстов, показанных на рис. 3.22.

Рис. 3.22. Изменение контекста при выполнении шаблона элемента month

Шаблон, вычисляемый в каждом из этих контекстов, имеет следующий вид:

<xsl:template match="month">

 <td>

  <xsl:value-of select="."/>

 </td>

</xsl:template>

Элемент xsl:value-of этого шаблона создает в элементе td текстовый узел, значение которого равно строковому значению выражения ".", то есть строковому значению текущего узла, и в каждом случае это будет строковое значение соответствующего элемента month.

Контекст преобразования позволяет более четко определить такие понятия, как "обработка узла", "применение шаблона к узлу" и так далее. Все эти выражения означают одно: выполнение соответствующего шаблона с данным узлом в качестве текущего.

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

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

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

□ результатом применения шаблонов к обрабатываемому множеству узлов является объединение фрагментов деревьев, которые являются результатами обработки каждого из узлов множества;

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

 • из всех шаблонов, определенных в данном преобразовании, выбираются шаблоны, соответствующие данному узлу (соответствие определяется паттерном, указанным в атрибуте match элемента xsl:template);

 • из этих шаблонов выбирается наиболее подходящий;

 • выбранный шаблон выполняется в контексте обрабатываемого множества как текущего множества узлов и обрабатываемого узла как текущего узла;

□ если шаблон содержит инструкции xsl:apply-templates или xsl:foreach, которые дополнительно выбирают узлы для обработки, процесс рекурсивно продолжается до тех пор, пока обрабатываемое множество будет содержать хотя бы один узел.

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

На сей раз, мы начнем с самых "глубоких" шаблонов — шаблонов, обрабатывающих элементы month.

<xsl:template match="month">

 <td>

  <xsl:value-of select="."/>

 </td>

</xsl:template>

Каждый из них создает результирующий фрагмент дерева следующего вида (рис. 3.23).

Рис. 3.23. Результат обработки элемента month

Шаблоны к элементам month применяются элементом xsl:apply-templates при обработке элемента summer соответствующим шаблоном:

<xsl:template match="summer">

 <table>

  <tr>

   <xsl:apply-templates select="month"/>

  </tr>

 </table>

</xsl:template>

Результатом выполнения xsl:apply-templates будет объединение результирующих фрагментов деревьев, которые получатся при обработке элементов month. Таким образом, результирующий фрагмент этого шаблона будет "собран" в следующем виде (рис. 3.24):

Рис. 3.24. Результат обработки элемента summer

Пунктиром выделены результирующие фрагменты деревьев, сгенерированные при обработке элементов month; эти фрагменты объединяются и используются при создании фрагмента дерева, являющегося результатом обработки элемента summer.

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

<xsl:template match="/">

 <html>

  <head>

   <title>Summer</title>

  </head>

  <body>

   <xsl:apply-templates select="summer"/>

  </body>

 </html>

</xsl:template>

Сгенерированный при обработке элемента summer результирующий фрагмент дерева включается в корневом шаблоне в элемент body (рис.3.25).

Рис. 3.25. Результат обработки корневого узла

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

Результирующий фрагмент дерева, полученный в результате обработки корневого узла, является деревом выходящего документа. В чистом XSLT это и есть результат выполнения преобразования. Для того чтобы получить физическую интерпретацию — в данном случае HTML-документ, дерево сериализуется, обращаясь в следующий выходящий документ.

Листинг 3.31. Выходящий документ проведённого преобразования

<html>

 <head>

  <title>Summer</title>

 </head>

 <body>

  <table>

   <tr>

    <td>June</td>

    <td>July</td>

    <td>August</td>

   </tr>

  </table>

 </body>

</html>

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

За исключением случаев упрощенных преобразований, корневым элементом XSLT-документа всегда является элемент xsl:stylesheet или его синоним xsl:transform. Эти элементы полностью идентичны и различаются только именами, поэтому мы будем описывать семантику и пользоваться только элементом xsl:stylesheet.

<xsl:stylesheet

 id="идентификатор"

 extension-element-prefixes="префиксы"

 exclude-result-prefixes="префиксы"

 version="число">

 <!--

  Содержимое: несколько элементов xsl:import, элементы верхнего уровня

 -->

</xsl:stylesheet>

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

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

<xsl:include

 href = "URI"/>

Обязательный атрибут href элемента xsl:include содержит URI внешнего модуля, который должен быть включен в текущее преобразование. Внешний модуль обязан быть корректным XSLT-преобразованием.

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

Рассмотрим простое преобразование a.xsl, которое определяет значение переменной date.

<xsl:stylesheet

 version="1.0"

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

 <xsl:variable name="date" select="'16.07.2001'"/>

</xsl:stylesheet>

Включим a.xsl в преобразование b.xsl.

<xsl:stylesheet

 version="1.0"

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

 <xsl:include href="a.xsl"/>

 <xsl:template match="/">

  <content>

   <xsl:text>Today is </xsl:text>

   <xsl:value-of select="$date"/>

   <xsl:text>.</xsl:text>

  </content>

 </xsl:template>

</xsl:stylesheet>

Включение в преобразование b.xsl преобразования a.xsl эквивалентно замене в b.xsl соответствующего элемента xsl:include на содержимое преобразования a.xsl. В нашем случае будет включено только определение переменной date. Преобразование b.xsl можно переписать в следующем виде: .

<xsl:stylesheet

 version="1.0"

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

 <xsl:variable name="date" select="'16.07.2001'"/>

 <xsl:template match="/">

  <content>

   <xsl:text>Today is </xsl:text>

   <xsl:value-of select="$date"/>

   <xsl:text>.</xsl:text>

  </content>

 </xsl:template>

</xsl:stylesheet>

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

Все ссылки и относительные идентификаторы ресурсов (URI), используемые во включаемом преобразовании, вычисляются относительно его базового адреса.

Предположим, что URI нашего преобразования имеет вид:

http://www.xsltdev.ru/examples/a.xsl

В этом случае элемент

<xsl:include href="b.xsl"/>

будет включать преобразование с URI

http://www.xsltdev.ru/examples/b.xsl

Нет никаких проблем и с включением преобразований по абсолютным идентификаторам. Например, если преобразование identity.xsl находится по адресу

http://www.xsltdev.ru/stylesheets/identity.xsl

то включить его можно элементом

<xsl:include href=" http://www.xsltdev.ru/stylesheets/identity.xsl"/>

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

В XSLT элементы xsl:import всегда должны быть первыми дочерними элементами головного элемента xsl:stylesheet. Поэтому элементы xsl:import внешнего преобразования включаются сразу после элементов xsl:import основного преобразования. Если в основном преобразовании элементов xsl:import нет, то включаемые элементы xsl:import становятся первыми дочерними элементами xsl:stylesheet основного преобразования.

Предположим, что в основное преобразование мы импортируем файл a.xsl и включаем файл b.xsl.

<xsl:stylesheet

 version="1.0"

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

 <xsl:import href="a.xsl"/>

 <xsl:variable name="a"/>

 <xsl:include href="b.xsl"/>

 <!-- Содержимое основного преобразования -->

</xsl:stylesheet>

<xsl:stylesheet

 version="1.0"

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

 <xsl:import href="c.xsl"/>

 <!-- Содержимое преобразования b.xsl -->

</xsl:stylesheet>

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

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:import href="a.xsl"/>

 <xsl: import href=f"c.xsl"/>

 <xsl:variable name="a"/>

 <!-- Содержимое преобразования b.xsl -->

 <!-- Содержимое основного преобразования -->

</xsl:stylesheet>

Элемент xsl:include можно использовать и для включения преобразований с упрощенным синтаксисом. Преобразования такого рода будут включаться как эквивалентные им преобразования стандартного синтаксиса — то есть с корневым элементом xsl:stylesheet и единственным шаблоном, соответствующим корневому узлу.

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

<html xsl:version="1.0"

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

 <xsl:apply-templates/>

</html>

Включим simple.xsl в основное преобразование.

<xsl:stylesheet

 version="1.0"

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

Другим способом использования внешних модулей в XSLT является импорт преобразований, который обеспечивается элементом xsl:import. Импорт преобразований более сложен, чем их простое включение — последовательность импорта модулей может влиять на то, как будет выполняться преобразование. Равно как и в случае с xsl:include, условное импортирование преобразований не разрешено.

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

<root>

 <a/>

 <b/>

</root>

<!DOCTYPE xsl:stylesheet [

 <!ENTITY ab SYSTEM "ab.xsl">

]>

<xsl:stylesheet

 version="1.0"

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

Тем, кому приходилось работать со стилями в HTML-документах, пожалуй будет знакома конструкция вида <LINK REL="stylesheet">, которая закрепляет за документом определенный стиль. Включив такую конструкцию, автор явным образом указывает, как следует отображать данный документ.

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

Для того чтобы закрепить XSLT-преобразование за XML-документом, в последнем должна быть использована инструкция по обработке xml-stylesheet, которая имеет следующий вид:

<?xml-stylesheet

 href="URI"

 type="тип"

 title="название"

 media="тип носителя"

 charset="кодировка"

 alternate="yes" | "no"?>

Заметим, что xml-stylesheet может закреплять за XML-документами не только преобразования. Основным назначением инструкции xml-stylesheet является ассоциация с документом фиксированного стиля (англ. stylesheet — стиль, стилевая таблица). С этой точки зрения преобразования являются не более, чем частным случаем стилевых таблиц.

Инструкция xml-stylesheet содержит шесть псевдоатрибутов (приставка псевдо- поясняет, что на самом деле инструкции по обработке не имеют атрибутов), два из которых, href и type, являются обязательными. Использование псевдоатрибутов xml-stylesheet поясняет табл. 4.2.

Как мы уже видели из множества примеров, преобразования состоят не только из элементов языка XSLT. Например, в шаблоне

<xsl:template match="b">

 <В/>

</xsl:template>

элемент B не принадлежит пространству имен XSLT и, следовательно, не считается XSLT-элементом. Такие элементы называются литеральными элементами результата (англ. literal result elements).

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

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

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

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

<xsl:template match="a">

 <A>

  <B/>

 </A>

</xsl:template>

При выполнении этого шаблона процессор создаст элемент A и включит в него обработанное содержимое — то есть элемент B. Результатом этого шаблона будет XML-фрагмент:

<А>

 <В/>

</А>

Теперь попробуем включить в содержимое элемента инструкцию XSLT:

<xsl:template match="a">

 <А>

  <xsl:value-of select="." />

 </A>

</xsl:template>

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

<a href="http://www.xsltdev.ru">Visit our site!</a>

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

<A>Visit out site!</A>

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

<xsl:template match="a">

 <A HREF="http://www.xsltdev.ru"

  xmlns:xhtml="http://www.w3.org/1999/xhtml">

  <xsl:value-of select="." />

 </A>

</xsl:template>

будет элемент вида:

<A HREF="http://www.xsltdev.ru"

 xmlns:xhtml="http://www.w3.org/1999/xhtml">

 Visit out site!

</A>

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

□ Процессор не будет копировать атрибуты, принадлежащие пространству имен XSLT.

□ Процессор не будет создавать узел пространства имен, соответствующий URI http://www.w3.org/1999/XSL/Transform, то есть URI пространства имен XSLT.

□ Процессор не будет создавать узлы пространств имен, префиксы которых исключаются атрибутами exclude-result-prefixes самого литерального элемента или элемента xsl:stylesheet.

<xsl:stylesheet

 version="1.0"

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

 xmlns:xhtml="http://www.w3.org/1999/XHTML">

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

Синтаксис этого элемента приведен ниже:

<xsl:template

 match="пaттерн"

 name="имя"

 priority="число"

 mode="имя">

 <!-- Содержимое: несколько элементов xsl:param, тело шаблона -->

</xsl:template>

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

Атрибут match задает паттерн — образец узлов дерева, для преобразования которых следует применять этот шаблон.

<xsl:template match="bold">

 <b><xsl:value-of select="."/></b>

</xsl:template>

В этом правиле атрибут match говорит о том, что оно должно использоваться для обработки элементов bold — в данном случае они будут заменяться на элементы b. Шаблоны, в которых определен атрибут match, вызываются при помощи инструкции xsl:apply-templates.

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

<xsl:template name="bold">

 <b><xsl:value-of select="."/></b>

</xsl:template>

В отличие от предыдущего примера, это правило не будет обрабатывать какие-либо определенные узлы. Вызвать его можно будет только по имени посредством элемента xsl:call-template.

При определении шаблона нужно обязательно указать хотя бы один из атрибутов match или name, причем эти атрибуты могут присутствовать в xsl:template одновременно.

Атрибут mode определяет режим данного шаблонного правила. Режимы позволяют задавать различные преобразования для одних и тех же частей документа (о них мы поговорим позже).

Атрибут priority используется для определения значения, которое называется приоритетом шаблонного правила. Это значение используется для разрешения конфликтов шаблонов в случае, когда один узел может быть обработан различными правилами.

Атрибуты шаблонного правила не влияют на выполнение его содержимого. Они используются элементами xsl:apply-templates и xsl:call-template при выборе шаблонов. Правила, которые были импортированы в преобразование, вызываются элементом xsl:apply-imports.

Рассмотрим следующий простой пример.

<para><bold>text</bold></para>

Попробуем написать пару шаблонов, которые будут изменять имена элементов para и bold на p и b соответственно. Сначала напишем преобразование для bold:

<xsl:template match="bold">

<b><xsl:value-of select="."/></b>

</xsl:template>

В этом правиле создается элемент b, в который включается текстовое значение текущего узла (то есть, обрабатываемого элемента bold). Применив это преобразование к входящему документу, мы получим следующий результат:

<b>text</b>

Как говорят математики, что и требовалось. Попробуем проделать тот же трюк с элементом para и создадим преобразование, включающее оба правила.

<xsl:stylesheet

 version="1.0"

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

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

<xsl:apply-templates

 select="выражение"

 mode="режим">

 <!-- Содержимое: несколько элементов xsl:sort или xsl:with-param -->

</xsl:apply-templates>

Элемент xsl:apply-templates применяет шаблонные правила к узлам, которые возвращаются выражением, указанным в атрибуте select. Если атрибут select опущен, то xsl:apply-templates применяет шаблонные правила ко всем дочерним узлам текущего узла, то есть

<xsl:apply-templates/>

равносильно

<xsl:apply-templates select="child::node()"/>

Атрибут mode используется для указания режима, в котором должны применяться шаблоны — мы поговорим о различных режимах чуть позже.

Прежде чем двигаться дальше, опишем более подробно, что означает "применить шаблон" (англ. apply — применить, template — шаблон). Применение шаблонов — это составная часть обработки документа, которая может быть описана следующим порядком действий.

□ На первом шаге процессор вычисляет выражение, указанное в атрибуте select. Его значением должно быть множество узлов. Полученное множество узлов упорядочивается и становится текущим списком узлов контекста преобразования.

□ Для каждого из узлов этого списка процессор находит наиболее подходящий шаблон для обработки. Процессор делает этот узел текущим и затем выполняет в измененном контексте выбранное шаблонное правило.

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

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

<xsl:stylesheet

 version="1.0"

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

 <xsl:template match="bold">

  <b><xsl:value-of select="."/></b>

 </xsl:template>

 <xsl:template match="para">

  <p><xsl:apply-templates</p>

 </xsl:template>

</xsl:stylesheet>

Проследим за процессом выполнения этого преобразования.

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

□ Шаблон, соответствующий элементу para, создает элемент p, содержимым которого будет результат выполнения инструкции xsl:apply-templates, то есть результат применения шаблонов к дочерним узлам текущего узла — элемента para.

□ Единственным дочерним узлом элемента para является элемент bold. Процессор изменит контекст так, что текущий список узлов будет содержать только элемент bold и выполнит соответствующее шаблонное правило, которое создаст элемент b и включит в него узел, вычисленный инструкцией <xsl:value-of select="."/>, то есть текстовый узел со строковым значением текущего узла, элемента bold.

Три шага этого преобразования продемонстрированы на рис. 5.1.

Рис. 5.1. Процесс преобразования

Здесь слева показан текущий список узлов, посередине — дерево документа с выделенным пунктиром текущим узлом, справа — генерируемое выходящее дерево.

Результатом этого преобразования будет документ:

<p><b>text</b></p>

Рассмотрим чуть более сложное преобразование документа:

<para>

 <bold>text1</bold>

 <para>

  <bold>text2</bold>

 </para>

</para>

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

□ Первым обрабатывается корневой узел. Процессор применяет шаблоны к дочерним узлам (вернее к одному дочернему узлу — элементу para).

□ Шаблон, обрабатывающий элемент para, создает в выходящем документе элемент p и применяет шаблоны к своим дочерним узлам — на этот раз их два, bold и para.

□ Шаблон, обрабатывающий элемент bold, создает в выходящем документе элемент b и текстовый узел со значением "text1".

□ Шаблон, обрабатывающий элемент para, создает в выходящем дереве узел p и применяет шаблоны к дочерним узлам.

□ Единственным дочерним узлом элемента para является элемент bold.

□ Шаблон, обрабатывающий этот элемент bold, создает в выходящем документе элемент b и текстовый узел со значением "text2".

Процесс преобразования показан на рис. 5.2.

Рис. 5.2. Процесс преобразования

Результатом этого преобразования будет документ:

<p>

 <b>text1</b>

 <p>

  <b>text2</b>

 </p>

</p>

Атрибут select элемента xsl:apply-templates позволяет выбирать, к каким именно узлам будет применяться этот шаблон. Значение select — это XPath-выражение, которое должно возвращать множество узлов. В случае, если атрибут select указан, шаблоны будут поочередно применяться к каждому из узлов выбранного множества.

Пример

Если при обработке элементов para мы хотим обрабатывать только дочерние элементы bold и никакие другие, шаблон обработки элементов para будет записан следующим образом:

<xsl:template match="para">

 <p><xsl:apply-templates select="bold"/></p>

</xsl:template>

Результатом обработки документа

<para>

 <bold>text1</bold>

 <para>

  <bold>text2</bold>

 </para>

</para>

будет теперь

<p>

 <b>text1</b>

</p>

Элемент para, который во входящем документе включен в другой элемент para, не будет обработан по той простой причине, что он не вошел во множество, выбранное XPath-выражением "bold". В то же время, если мы запишем

<xsl:template match="para">

 <p><xsl:apply-templates select="bold|para"/></p>

</xsl:template>

то результат будет таким же, как и прежде:

<p>

 <b>text1</b>

 <p>

  <b>text2</b>

 </p>

</p>

Следует хорошо понимать разницу между атрибутом select элемента xsl:apply-templates и атрибутом match элемента xsl:template. Атрибут match содержит не XPath-выражение, а паттерн XSLT; в отличие от атрибута select в xsl:apply-templates он не выбирает никакого множества узлов, он используется только для того, чтобы проверить, может ли данный узел обрабатываться этим шаблоном или нет.

Атрибут select элемента xsl:apply-templates наоборот, содержит не паттерн, а выражение, единственным требованием к которому является то, что оно должно возвращать множество узлов. Например, некорректным будет определение вида

<xsl:apply-templates select="para+1"/>

поскольку выражение para+1 не может возвратить множество узлов.

Кроме этого требования, никаких других ограничений на выражения в этом атрибуте нет. В нем можно использовать переменные, содержащие множества узлов, функции, возвращающие множества узлов (например, такие, как id или key), выражения с операциями над множествами (именно таким выражением — выражением объединения было выражение bold|para), пути выборки, фильтрующие выражения, в общем, любые выражения, которые только могут возвращать множества. Например, для того, чтобы обработать содержимое произвольного внешнего XML-документа, в атрибуте select элемента xsl:apply-template следует использовать функцию document.

Пример

Объявление вида

<xsl:apply-templates select="document('a.xml')//para"/>

применит шаблоны ко всем элементам para документа a.xml.

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

Имя шаблонному правилу присваивается атрибутом name элемента xsl:template. После этого шаблону более необязательно иметь атрибут match, теперь он может быть вызван просто по имени. Два шаблона с одним порядком импорта не могут иметь одинаковых имен. Если же одинаковые имена имеют шаблоны различного порядка импорта, шаблоны старшего порядка переопределяют младшие шаблоны

При генерации HTML-страниц часто встречающейся задачей является создание элемента head. Элемент head, как правило, содержит несколько элементов meta, предоставляющих метаинформацию, элемент title, который определяет название страницы и элемент link, который связывает данную страницу с другими документами, например, с каскадными таблицами стилей (CSS).

Для того чтобы упростить процедуру генерации head, мы можем вынести ее в отдельный именованный шаблон.

<xsl:template name="head">

 <head>

  <meta name="keywords" content="XSLT, XPath, XML"/>

  <meta name="description"

   content="This site is dedicated to XSLT and Xpath."/>

  <title>XSLTdev.ru - XSLT developer resource</title>

  <link rel="stylesheet" type="text/css" href="style/main.css"/>

 </head>

</xsl:template>

Думается, этот шаблон не требует пояснений — он просто создает в входящем документе несколько элементов. Непонятным пока остается другое — как вызывать именованные шаблоны? Элемент xsl:apply-templates явно не подходит, поскольку именованные шаблоны не обязаны иметь атрибут match. Их выполнение производится элементом xsl:call-template.

Приведем синтаксис этого элемента:

<xsl:call-template

 name="имя">

 <!-- Содержимое: несколько элементов xsl:with-param -->

</xsl:call-template>

Обязательный атрибут name указывает имя шаблона, который вызывается этой инструкцией. Например, шаблон с именем "head", приведенный выше, может быть вызван следующим образом:

<xsl:call-template name="head"/>

Атрибут name при вызове обязан иметь фиксированное значение — точно так же, как и в случае с mode и xsl:apply-templates, динамика здесь не разрешена.

При вызове xsl:call-template не изменяет контекста преобразования. Фактически, вызов именованного шаблона эквивалентен замене в тексте преобразования элемента xsl:call-template на тело вызываемого шаблона.

Приведем пример.

<content>

 Just a few words...

</content>

<xsl:stylesheet

 version="1.0"

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