XSLT

Холзнер Стивен

<NAME>1.1.1. Mercury</NAME>

<MASS>1.1.2. .0553</MASS>

<DAY>1.1.3. 58.65</DAY>

<RADIUS>1.1.4. 1516</RADIUS>

<DENSITY>1.1.5. .983</DENSITY>

<DISTANCE>1.1.6. 43.4</DISTANCE><!--В перигелии-->

 </PLANET>

 <PLANET>1.2.

<NAME>1.2.1. Venus</NAME>

<MASS>1.2.2. .815</MASS>

<DAY>1.2.3. 116.75</DAY>

<RADIUS>1.2.4. 3716</RADIUS>

<DENSITY>1.2.5. .943</DENSITY>

<DISTANCE>1.2.6 66.8</DISTANCE><!--В

перигелии-->

 </PLANET>

 <PLANET>1.3.

<NAME>1.3.1. Earth</NAME>

<MASS>1.3.2. 1</MASS>

<DAY>1.3.3. 1</DAY>

<RADIUS>1.3.4. 2107</RADIUS>

<DENSITY>1.3.5. 1</DENSITY>

<DISTANCE>1.3.6. 128.4</DISTANCE><!--В перигелии-->

 </PLANET>

</PLANETS>

На этом мы завершаем рассмотрение нумерации документов и переходим к последней теме этой главы — расширяемости XSLT.

Расширяемость XSLT

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

<saxon:while>

, реализуя в XSLT стандартный для программирования цикл

while

(до тех пор, пока). Xalan представил такие элементы, как

<redirect:write>

, для поддержки вывода нескольких документов. А процессор MSXML3 от Microsoft позволяет писать функции на языках таких сценариев, как JavaScript, и затем вызывать их и выполнять их код.

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

• расширения должны использовать пространства имен

во избежание конфликтов с элементами XSL;

• процессор XSLT должен быть в состоянии распознать применение расширения — и в случае ошибки расширения реагировать хорошо определенным способом;

• таблица стилей должна быть в состоянии проверить, доступно ли определенное расширение, и если нет, вернуться назад.

НОВОЕ В XSLT 2.0

Легко представить сложности W3C даже с этими общими правилами, и комитет XSLT 2.0 собирается исследовать возможность реализации всех расширений на «чистом» XSLT, вообще не прибегая к каким-либо внешним языкам программирования.

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

В XSLT 1.0 проверить доступность функции расширения можно при помощи функции

function-available

, а доступность элемента расширения — при помощи функции

element-available

.

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

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

ИНИЦИАТИВА EXSLT

Теперь, после того, как механизмы расширения в рабочем проекте XSLT 1.1 были отложены до XSLT 2.0, роль других разнообразных попыток стандартизации расширений XSLT значительно повысилась. Познакомьтесь, например, с EXSLT на www.exslt.org. EXSLT — это инициатива открытого сообщества, работающего над стандартизацией расширений XSLT.

Функции расширения

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

starpowder:calculate

. В XSLT 1.0 также имеется функция

function-available

для проверки наличия функции по ее имени.

В рабочем проекту XSLT 1.1 на функции расширения были наложены некоторые дополнительные ограничения:

• функции расширения должны работать как встроенные функции;

• для Java и ECMAScript должны быть реализованы привязки к языку;

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

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

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