New features for XSLT 2.0 and XPath 2.0

SLT 2.0 with XPath 2.0. They are described separately because XPath 2.0 can also be used in environments other than XSLT, such as XQuery 1.0. But for XSLT users, they are interrelated. You cannot use XPath 2.0 in XSLT 1.0, or use XPath 1.0 in XSLT 2.0. (at least so far, there is no proposal for this combination.) ）

Note

You might ask: What happened to XSLT 1.1? XSLT 1.1 has been canceled. Officially, in August 2001, in fact, a few months ago, the XSLT working Group aborted XSLT 1.1, concentrating on developing XSLT and XPath 2.0, and transferring the pre-requirements of XSLT 1.1 to XSLT 2.0.

Welcome to come

Many XSLT users are largely involved in the new version of the XSLT development process. As with the first edition of many languages, it is often unclear which extensions of the language are proven to be the most important without a practice test. Since the November 16, 1999 XSLT 1.0 has become a recommendation, it is clear that some of the missing features should be included in the next release, and this article will look at XSLT 2.0 from the following four aspects:

• Conversions from result tree fragments (result trees fragments) to node set (node-sets)
• Documents with multiple outputs
• Intrinsic support for grouping
• User-defined functions (implemented in XSLT)

The end of RTF

In XSLT 1.0, the result tree fragment (Result trees fragment,rtf) type is much like a node-set, but is actually a second-class citizen. When you use the xsl:variable build a temporary tree, you get the RTF. The problem is that you cannot use XPath expressions to access the contents of this tree unless you use a vendor-supplied extension function, usually node-set (), to convert the RTF into a class of node sets (with one root node). The existence of this RTF data type is intended to reduce implementation limitations, but this is impractical because almost all XSLT processors provide node-set() extension functions such as these. In any case, the call to break this limit is always more pronounced, because it is important to break down complex transformations into a series of simple transformations.

I don't know if you guessed it, XSLT 2.0 opens the door for RTF. Now when you use xsl:variable create a temporary tree, the value of this variable is a true node set. In fact, in the terms of the XPath 2.0, it is a true node sequence ( sequence), which contains a document node (this is the name of an XPath 2.0, The "root node" of XPath 1.0). In this sequence you can use an XPath expression to drill down into the tree, apply a template to it, and so on, just as you would with other source files. With XLST 2.0 It is no longer necessary to node-set() extend functions like this.

Allow Multiple output documents

Another extension provided by many XSLT 1.0 processors is multiple output documents, which proves to be very useful, especially for static generation of sites with multiple pages. The problem is that this extension is not a standard feature. Each processor does not have the same elements to complete this extension, such as Saxon:output, Xt:document, and so on.

XSLT 2.0 uses   the xsl:result-document element provides a standard method for multiple output documents. The following style sheet example builds multiple output documents, a "primary result file" and several "secondary result files." The primary result file is stored in XHTML, and secondary result files are stored in plain text.

<xsl:stylesheet version= "2.0" xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" xmlns= "http://www.w3.org/1999/ XHTML "> <xsl:output method=" xhtml "/> <xsl:output method=" text "name=" TextFormat "/> <xsl:template Match= "/" > result-documentHref= "{$uri}" format= "TextFormat" > <xsl:value-of select= "." /> </xsl:result-document> </xsl:template></xsl:stylesheet>

xsl:document  href  property is used to specify a URI for the corresponding output file. For many processors, this means storing files with the file name. Instead format , the property is used to reference a named specified output. Here, it points to the Xsl:output element named TextFormat.

The XHTML output in the example above is also newly introduced in XSLT 2.0, which is not to be described here.

Simplified grouping

XSLT 1.0 does not have intrinsic support for grouping. Certain grouping problems can undoubtedly be solved using a variety of techniques, such as the Muenchian method, but the solution is quite complex and difficult to understand. One of the requirements for XSLT 2.0 is the need to simplify grouping, as we saw in the following example, which satisfies the requirements.

The example that appears in the Requirements document and XSLT 2.0 work draft is about putting a list of cities in the following simple XML document,

<cities>  <city name= "Milan"  country= "Italy"   pop= "5"/>  <city name= "Paris"  Country= "France"  pop= "7"/>  <city name= "Munich" country= "Germany" pop= "4"/>  <city name= " Lyon "   country=" France "  pop=" 2 "/>  <city name=" Venice "country=" Italy "   pop=" 1 "/></ Cities>

Convert to a country-grouped HTML table as follows:

<table>   <tr>      <th>Country</th>      <th>city list</th>      <th> population</th>   </tr>   <tr>      <td>italy</td>      <td>milan, venice</td>      <td>6</td>   </tr>   <tr>      <td>france</td>      <td>paris, lyon</td>      <td>9</td>   </tr>   <tr>      <td >germany</td>      <td>munich</td>      <td>4</td>   </tr></ Table>

The difficulty with this conversion is to generate the last three rows (as shown in bold). Here is a solution for XSLT1.0:

  <xsl:for-each select= "cities/city[not (@country =                           preceding::*/@country)]" >    <tr>      <td ><xsl:value-of select= "@country"/></td>      <td>        <xsl:for-each select= ". /city[@country = current ()/@country] ">          <xsl:value-of select=" @name "/>          <xsl:if test=" position () ! = Last () ", </xsl:if>        </xsl:for-each>      </td>      <td><xsl:value-of select= The sum (.. /city[@country = Current                 ()/@country]/@pop) "/></td>    </tr>  </xsl:for-each>

In the example above, for each particular country, we first use the following XPath expression to find its first city:

Cities/city[not (@country = preceding::*/@country)]

Then, for each grouping, in order to get a list of the city names of each country and the total population of the country, we need to go back to referencing all the other members of the group, both of which we have to do some extra work, because only the following expressions can be used to refer to the current grouping:

.. /city[@country = current ()/@country]

Obviously this is not an ideal situation, because this extra code is often the source of the error. With xsl:for-each-group , XSLT 2.0 provides answers to most of your grouping questions. Here's how XSLT2.0 solves the problem (bold indicates the new feature):

  <xsl:for-each-groupgroup-by= "@country" >    <tr>      <td><xsl:value-of select= "@country"/></td>      <td>        <xsl:value-of select= "current-group ()  Separator= ","/>      </td>      <td><xsl:value-of select= "sum (current-group () /@pop) "/></td>    </tr>  </xsl:for-each-group>

In the example above, the xsl:for-each-group current group is initialized as part of the context of the XPath's accessor and is a simple sequence. Once we have group-by set up the grouping using attributes, we can current-group() later use the function to refer to the current grouping. This completely eliminates the extra overhead in the XSLT1.0 scenario.

Note xsl:value-of the separator properties in. The existence of this property is to tell the processor not just to output the string value of the first element in the sequence (XSLT1.0 is so), but to sequentially output the values of all the elements in the sequence. The value of the separator property is an optional string that is used as the delimiter for each string in the output. To be compatible with XSLT1.0, if no separator attribute is specified, only the value of one member in the sequence is output.

Finally, depending on xsl:for-each-group the value of the three attributes, different grouping problems can be resolved: group-by (as shown above), goup-adjacent (used to group adjacent relationships based on the order of the nodes in the text, such as the <para of the inline The > elements are converted to block-level <para> elements, and group-start-with (grouped by the pattern of elements in the sequence (patterns)). Examples of these methods can be found in the latest XSLT2.0 work draft "13.3 Examples of Grouping".

User-defined Functions

XSLT2.0 introduces a new feature that allows you to define their own functions and can be used in XPath expressions. This is a very powerful feature that is undoubtedly very useful. A style function (Stylesheet functions) is xsl:function defined with an element. This element must specify a name property. It contains 0 or more xsl:param elements, followed by 0 or more xsl:variable elements xsl:result , followed by a unique element. This rigorous content model seems to be a limitation, but you will find that the real strength of XSLT2.0 is the xsl:result attribute of the definable select element. You might think that XPath2.0 has conditional expressions ( if...then ) and Iterations (iterative) (enumerated?). ) expression ( for...return ).

As shown in the following example (directly from the latest work draft), many of the work is xsl:result done in the select properties. This style sheet invokes a user-defined recursive function str:reverse() to output the string "Man Bites DOG".

<xsl:transform   xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform"  xmlns:str= "http://user.com/ Namespace "  version=" 2.0 "  exclude-result-prefixes=" str "><xsl:function name=" Str:reverse ">  <xsl:param name= "sentence"/>  <xsl:result      select= "if (Contains ($sentence, ')") then             concat (str : Reverse (Substring-after ($sentence, ")),"                         ,                         Substring-before ($sentence, "))             else $sentence"/>             </xsl:function><xsl:template match= "/" ><output>  <xsl:value-of select= "STR: Reverse (' DOG bites man ') "/></output></xsl:template></xsl:transform>

Other useful things.

XSLT2.0 There are other useful new features that we can hardly be described here. Includes a mechanism to define the default namespace (namespace) of an XPath expression that can be used in a pattern matching decision (match pattern predicates) to name the sort description (named sort specifications), Read into the external file in non-parsed text (unparsed text), and so on.

In addition, a large part of the XSLT2.0 specification is still in development, especially with regard to building and replicating the content of the XML schema type. With regard to this, the latest work in the draft says, "This work is in progress, and the association of type information about building elements and attributes will likely appear in future versions of the XSLT2 draft." Progress. Facilities for associating type information with constructed elements and attributes is likely to appear in the future drafts of XSLT 2) ".

New features for XSLT 2.0 and XPath 2.0