Читать онлайн «Технология XSLT». Страница 20

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

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

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

□ результат преобразования возвращается клиенту (например, в виде 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 прекрасно справляется с этой задачей, предоставляя широкие возможности для структурного оформления данных в текстовом виде. Вместе с тем, во многих случаях просто выделить данные было явно недостаточно, поскольку помимо машинной обработки они также должны были быть понятны человеку. В качестве примера, вспомним рекламное объявление, которое мы разметили в первой главе:

<advert>

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

 <product>Холодильник</product>

 <product-title>"Горск"</product-title>

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

 рублей!

 <!-- И так далее -->

</advert>

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

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