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

Таблица 10.1. Использование расширений: критерии за и против

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

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

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

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

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

:

Атрибут

содержит XPath-выражение , которое с точки зрения синтаксиса XPath является вызовом функции и соответствует продукции :

Аргументами функции являются выражения, а имя может быть любым корректным XML-именем (за исключением

, , и , которые используются для проверки типа узла):

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

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

Выражение

является вызовом функции базовой библиотеки XPath, в то время как выражение

является вызовом функции расширения.

Практически во всех процессорах пространство имен функции расширения является звеном, которое связывает ее с конкретной реализацией.

Элемент

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

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

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

Примечание

SVG — это XML-язык для описания масштабируемой векторной графики (от англ. scalable vector graphics). SVG позволяет простым XML-синтаксисом описывать векторную графику. SVG-документы могут показываться в браузерах при помощи таких компонент, как Adobe SVG Viewer или Batik от Apache XML Project.