Технология XSLT

Преобразования снаружи

В общем случае в преобразовании участвуют три документа:

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

□ документ, который описывает само преобразование;

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

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

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

Рис. 2.1. Схема XSLT-преобразования

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

Рис. 2.2. Древовидные структуры в XSLT

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

□ XSLT-процессор разбирает входящий документ и документ преобразования, создавая для них древовидные структуры данных. Этот этап называется этапом парсинга документа (от англ. parse — разбирать).

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

□ Для созданного дерева генерируется физическая сущность. Этот этап называется этапом сериализации.

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

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

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

Рис. 2.3. Сериализация в XSLT

Текущая версия языка поддерживает три основных метода сериализации: XML, HTML и текст. Каждый из этих методов учитывает синтаксис целевого физического формата и позволяет получить документ требуемого вида. Кроме того, имплементации XSLT могут добавлять собственные методы сериализации, генерируя документы в других форматах (например, PDF или TeX), не предусмотренных стандартными методами.

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

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

Области применения XSLT

XSLT в архитектуре клиент-сервер

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

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

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

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

Схема взаимодействия XML и XSLT в архитектуре клиент-сервер представлена на рис. 2.4. На этом рисунке нет четкой границы, которая отделяла бы клиента от сервера. Дело в том, что существует два принципиально различных способа использования XSLT в подобной архитектуре: преобразования могут выполняться как на стороне сервера, так и на стороне клиента. Рассмотрим подробнее оба способа.

Рис. 2.4. XML и XSLT в архитектуре клиент-сервер

XSLT на стороне сервера

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

Рис. 2.5. XSLT на стороне сервера

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

XSLT на стороне клиента

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

Рис. 2.6. XSLT на стороне клиента

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

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

XSLT при обмене данными

В предыдущей главе мы обсудили преимущества применения 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-технологиях).

История XSLT

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

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

 Холодильник

 "Горск"

 объемом 250 л. и стоимостью всего 4500

 рублей!

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

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

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

Приведенные выше причины могут объяснить потребность в стандартной технологии для презентации XML-документов — технологии, подобной DSSSL (Document Style Semantics and Specification Language, язык семантики и спецификации стиля документа), которая существовала для SGML или CSS (Cascading Style Sheets — каскадные таблицы стилей) для HTML. Эта технология получила название XSL (extensible Stylesheet Language — расширяемый язык стилей), и именно ей обязан своим возникновением язык XSLT.

Первые идеи о создании отдельного языка для презентации документов были представлены на конференции WWW'94, где С.М. Шперберг-МакКвин и Роберт Гольдштейн выступили с докладом об использовании возможностей SGML во всемирной паутине. В этом докладе были сформулированы основные принципы языка стилей. Мы перечислим некоторые из них:

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

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

□ презентация элемента может изменяться в зависимости от расположения этого элемента в документе;

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

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

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

Язык XSL виделся тогда более простым и понятным, чем DSSSL и более мощным, чем CSS. Уже тогда разработчики понимали, что язык презентации XML-документов не сможет обойтись без преобразования их структуры, расширений и должен быть основан на множестве правил презентации.

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

После того, как требования к XSL были, наконец, сформулированы, разработка языка вылилась в создание целой серии черновых рабочих вариантов (в терминах W3C — working drafts, WD). Эти варианты зачастую сильно различались между собой, однако основные принципы XSL соблюдались в них неукоснительно.

С первых же рабочих версий XSL стало понятно, что задача презентации XML-документов состоит из двух главных подзадач: преобразование документа и описание внешнего вида результата этого преобразования. Разделение это было настолько четким, что спецификацию XSL более или менее независимо редактировали два человека: Джеймс Кларк (James Clark) и Стивен Дич (Stephen Deach). Кларк отвечал за преобразования (что в первых версиях называлось tree construction — конструирование дерева), Дич редактировал презентационную часть XSL (которую назвали formatting objects — форматирующие объекты).

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

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

Таким образом, технология XSL разделилась на три составные части: язык преобразований XSLT, язык обращений к XML-документам XPath и язык стилей XSL. На рис. 2.12 в графической форме показано развитие XSL с момента создания первой рабочей версии в августе 1998 года и до настоящего времени. Вершины графа соответствуют опубликованным версиям языков. WD означает working draft (рабочий черновой вариант), CR — candidate recommendation (кандидат в рекомендации), PR — proposed recommendation (предлагаемая рекомендация) и REC — рекомендация. Для тех, кто не знаком с деятельностью Консорциума W3 поясним, что любая технология, которой занимаются рабочие группы W3C, проходит ряд этапов: формирования требований, несколько рабочих версий, кандидат в рекомендации и предлагаемая рекомендация. Если все проходит успешно, технология становится технической рекомендацией Консорциума W3, что имеет статус стандарта де-факто (с тем лишь отличием, что стандарты могут принимать только организации, уполномоченные правительствами).

Рис. 2.12. История развития языка XSL в виде графа

Что касается XSLT и XPath, спецификации обоих этих языков стали техническими рекомендациями 16 ноября 1999 года. Сам же язык XSL, который теперь стали называть XSL-FO (аббревиатура FO означает formatting objects — форматирующие объекты), получил статус рекомендации не так быстро. Спустя год, в ноябре 2000, спецификация XSL получила статус кандидата в рекомендации, а еще через 9 месяцев с минимальными исправлениями — статус предлагаемой рекомендации. По всей видимости, к тому моменту, когда эта книга увидит свет, спецификация XSL уже будет официальной рекомендацией W3C.

Одного года было достаточно, чтобы XSLT стал широко использоваться во многих XSLT-задачах. Повышенное внимание разработчиков позволило выявить некоторые досадные огрехи, которые были допущены в первой версии XSLT, и потому в конце 2000 года была начата работа над версией 1.1. В новой версии рабочая группа XSL постаралась исправить большинство ошибок, допущенных в версии 1.0 и добавить некоторые возможности, которых не хватало в первой версии. Однако через некоторое время стало понятно, что разрабатываемый язык довольно сильно отличается от первой версии. К тому же, с учетом таких разработок, как XML Schema и XQuery возникла необходимость изменить модель данных и выражений XPath. В итоге, работу над версией 1.1 решено было прекратить и переключиться на создание вторых версий языков XSLT и XPath.

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