<TD>1516 miles</TD>
<TD>58.65 days</TD>
</TR>
<TR>
<TD>3. Venus</TD>
<TD>.815 (Earth = 1)</TD>
<TD>3716 miles</TD>
<TD>116.75 days</TD>
</TR>
<TR>
<TD>4. Earth</TD>
<TD>1 (Earth = 1)</TD>
<TD>2107 miles</TD>
<TD>1 days</TD>
</TR>
</TABLE>
</BODY>
</HTML>
При помощи атрибута from можно указать, с какого узла-предка начинать отсчет; например, если установить узел-предок в элемент <PLANET> так:
<xsclass="underline" number level="any" count="NAME" from="PLANET"/>
то процессор XSLT осуществит обратный просмотр только до первого предка <PLANET> и начнет нумерацию с этой точки документа.
Многоуровневая нумерация
Элемент <xsclass="underline" number> также поддерживает многоуровневую нумерацию — такую как 3.1.2.5 и т. п. Для работы с ней нужно установить атрибут level в «multiple». При помощи атрибута count можно указать, узлы какого типа вы хотите нумеровать, установив этот атрибут в образец, например: "PART|CHAPTER|PARAGRAPH". При обработке элементов <xsclass="underline" number> процессор XSLT нумерует узлы в соответствии с иерархией документа.
В примере я нумерую каждый уровень в иерархии элементов planets.xml, установив атрибут count в «*» для выбора всех элементов. Можно также указать формат нумерации при помощи атрибута format. При многоуровневой нумерации атрибут format задает формат для различных уровней, например «1.1.1.» задает нумерацию 1., 2., … и т.д. для узлов верхнего уровня, 1.1., 1.2., … и т.д. для узлов уровнем ниже и 1.2.1., 1.2.2., … и т. д. для следующего уровня вниз. Вот как выглядит таблица стилей для этого примера в листинге 5.13.
Листинг 5.13. Многоуровневая нумерация
<?xml version="1.0"?>
<хsclass="underline" stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsclass="underline" output method="xml"/>
<xsclass="underline" template match="node()">
<xsclass="underline" copy>
<xsclass="underline" number format="1.1.1." level="multiple" count="*"/>
<xsclass="underline" apply-templates select="node()"/>
</xsclass="underline" copy>
</xsclass="underline" template>
</xsclass="underline" stylesheet>
Вот результат преобразования planets.xml в новый XML-документ, в котором перенумерованы все уровни элементов в соответствии с иерархией документа:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xml" href="planets.xsl"?>
<PLANETS>1.
<PLANET>1.1.
<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, вообще не прибегая к каким-либо внешним языкам программирования.