XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (13 page)

The Development of XSLT 2.0 and XPath 2.0

The requirements for XSLT 2.0 and XPath 2.0 were published on February 14, 2001. In the case of the XPath 2.0 requirements, the document was written jointly by the two working groups. You can find the documents at the following URLs:

Broadly, the requirements fall into three categories:

• Features that are obviously missing from the current standards and that would make users' lives much easier, for example, facilities for grouping related nodes, extra string-handling and numeric functions, and the ability to read text files as well as XML documents.
  
• Changes desired by the XML Query Working Group. The difficulty at this stage was that the Query group did not just want additions to the XPath language; they wanted fundamental changes to its semantics. Many members of the XQuery group felt they could not live with some of the arbitrariness of the way XPath handled data types generally, and node-sets in particular, for example the fact that
  a = 1
  tests whether there is some
  a
  that equals one, whereas
  a − 1 = 0
  tests whether the first
  a
  equals one.
  
• Features designed to exploit and integrate with XML Schema. The W3C XML Schema specification had reached an advanced stage (it became a Candidate Recommendation on October 20, 2000), and implementations were starting to appear in products. The thinking was that if the schema specified that a particular element contains a number or a date (for example), then it ought to be possible to use this knowledge when comparing or sorting dates within a stylesheet.
  

The development of XSLT 2.0, culminating in the Recommendation of January 23, 2007, proved to be a long drawn out process. There were early delays getting agreement with the XQuery group on the details of XPath 2.0. This took a long time firstly, because of the number of people involved; secondly, because of the very different places where people were coming from (the database community and the document community have historically been completely isolated from each other, and it took a lot of talking before people started to understand each others' positions); and finally, because of the sheer technical difficulty of finding a workable design that offered the right balance between backwards compatibility and rigorous, consistent semantics. Later, when the specification appeared to be all but finished, it still took a couple of years to get through the public reviews demanded by the W3C process, which generated thousands of detailed comments.

But that's all history now. Let's look next at the essential characteristics of XSLT 2.0 as a language.

XSLT 2.0 as a Language

What are the most significant characteristics of XSLT as a language, which distinguish it from other languages? In this section I shall pick five of the most striking features: the fact that it is written in XML syntax, the fact that it is a language free of side effects, the fact that processing is described as a set of pattern-matching rules, the fact that it has a type system based on XML Schema, and the fact that it is a two-language system in which one language (XPath) is embedded in another (XSLT).

Use of XML Syntax

As we've seen, the use of SGML syntax for stylesheets was proposed as long ago as 1994, and it seems that this idea gradually became the accepted wisdom. It's difficult to trace exactly what the overriding arguments were, and when you find yourself writing something like:

to express what in other languages would be written as
y = f(x);
, then you may find yourself wondering how such a decision came to be made.

The most obvious arguments for expressing XSLT stylesheets in XML are perhaps as follows:

• There is already an XML parser in the browser; so it keeps the footprint small if this can be reused.
  
• Everyone had got fed up with the syntactic inconsistencies between HTML/XML and CSS and didn't want the same thing to happen again.
  
• The Lisp-like syntax of DSSSL was widely seen as a barrier to its adoption; so it would be better to have a syntax that was already familiar in the target community.
  
• Many existing popular template languages (including simple ASP and JSP pages) are expressed as an outline of the output document with embedded instructions; so this is a familiar concept.
  
• The lexical apparatus is reusable, for example Unicode support, character and entity references, whitespace handling, namespaces.
  
• Visual development tools remove the inconvenience of typing lots of angle brackets.
  
• It's often useful to have a stylesheet as the input or output of a transformation; so it's a benefit if a stylesheet can read and write other stylesheets.