Introduction

Evan Lenz

I'm not sure whether there is a particular consensus on this list. I think there are a number of welcome features that people have been asking for for some time in XSLT 2.0, such as the elimination of the result tree fragment type, built-in support for grouping, support for multiple output documents, user-defined functions in XSLT, etc. But I think it's also pretty clear that XPath 2.0 has gone well beyond what most users (at least on this list) have been asking for. This is the natural result when two working groups get together and try to meet both of their requirements in a single common language. I am generally pretty happy with the progression of the language, how backward-compatible it is, and how much power it brings to users, as demonstrated by the solution to your problem. In any case, I don't see XSLT 1.0 dying off any time real soon.

Some people are concerned about the sheer number of functions and operators in XPath 2.0 (almost five times as many as in 1.0). A related issue is XPath 2.0's heavy dependence on XML Schemas. I personally share some of these concerns. The real test of the specification's success is the number and quality of implementations. Saxon 7 is a good pioneer. It would be great (even crucial) to see more efforts sprout up before we approach Recommendation status.

There are also some widely-requested features slated for inclusion but yet to be published, such as support for regular expressions (an XPath 2.0 requirement). There also remains a good chunk of work to do on XSLT 2.0's support for the construction of XML Schema-typed content.

I wrote a couple basic introductions[1-2] to XPath 2.0 and XSLT 2.0 on XML.com, if you're interested.

Evan (speaking only for himself, not for the XSL WG)

[1][1] [2] [2]

Michael Kay

If you have two adjacent strings in the sequence used to construct an element node, a space will be inserted between them. So if you do this:

<a>
  <xsl:sequence select="'aaa'"/>
  <xsl:sequence select="'bbb'"/>
</a>

the result will be

<a>aaa bbb</a>

There are various ways you can avoid this effect, for example:

<a>
  <xsl:sequence select="concat('aaa','bbb')"/> </a>

<a>
  <xsl:value-of separator="">
    <xsl:sequence select="'aaa'"/>
    <xsl:sequence select="'bbb'"/>
  </xsl:value-of>
</a>

<a>
  <xsl:value-of select="'aaa'"/>
  <xsl:value-of select="'bbb'"/>
</a>

Eliot Kimber

After a period of serious doubt about XSLT 2 and it's advantages over XSLT 1.0, driven largely by concerns about the implications of schema-aware processing and datatypes, I must say that I am now firmly convinced of the value of XSLT 2.

One thing I realized is that the datatyping stuff is only an issue if you do schema-aware XSLT processing. But for a lot of stuff you don't need schema awareness so it's not an issue. In particular, processing schema-based documents does not necessarily imply schema-aware XSLT processing (but it does enable it).[1]

In particular, I'm finding that the for-each-group, namespace aliasing, and string handling features are making many problems much much easier than they were with 1.0. In addition, the ability to create XSLT functions makes it easier to have a more object-oriented style of code without limiting your XSLT to a single or small set of engines, as was the case with XSLT 1. In addition, the new concept of sequence constructors in XSLT 2 makes many operations, especially in the context of functions, much clearer and more reliable.

The for-each-group stuff is just brilliant. I didn't really appreciate just how powerful it was until I started using it. For example, here's a script that uses for-each-group to report the set of unique element types used in a document:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
version="2.0"
 >

  <xsl:template match="/">
    <xsl:message>
      Unique Element Types:

    </xsl:message>
    <xsl:for-each-group select="//*"
         group-by="name()"
    >
      <xsl:sort select="name()"/>
      <xsl:message><xsl:value-of 
select="current-grouping-key()"/></xsl:message>
    </xsl:for-each-group>
  </xsl:template>
</xsl:stylesheet>

I think that's pretty cool (not the script, but the fact that you can do this with such little code).

Anyway, my hat is off to the XSLT 2 Working Group and my thanks go out to implementors of XSLT 2 engines, especially Mike Kay for Saxon 8.

[1]Schema-aware XSLT processing is *not* the same as applying an XSLT to a schema-based document where the document is validated on input to the XSLT. In this case, the XML processor validates the document against its schema and augments the info set passed to the XSLT engine to reflect things like schema-defined default values, but the XSLT engine will still treat all attribute values and element content as the generic "any type". It's only in the case where the XSLT processor *also* accesses the schema in order to determine the full datatype of attributes and content that you can get weirdness in your XSLT as a result of values being returned as types you didn't expect. The implication here is that you either write an XSLT script as completely schema unaware or as completely schema aware and make sure you configure your XSLT processor appropriately.

-

3 IBM developerworks articles on XSLT 2.0 IBM developerworks