RE: [xml-dev] Inside every fat book is a thin book trying to get out (a

["Michael Kay" <mike@saxonica.com>]

> 
> Although XSLT/XPath 1.0 doesn't have all the whiz-bang stuff 
> of XSLT/XPath 2.0, it mostly does everything that is needed 
> for transforming an XML document.  
> 
> Compare the sizes of the specifications for XSLT and XPath 
> 1.0 and 2.0:
> 
> 
> XSLT 1.0  ... 94 pages
> XPath 1.0 ... 33 pages
> 
> XSLT 2.0  ... 374 pages
> XPath 2.0 ... 340 pages 
> 

There are two reasons for the growth: one is that the language has grown,
the other is that it is specified in more detail.

Most of the growth in the languages was needed, I think: experience suggests
that there are very few features in XPath 2.0 or XSLT 2.0 which haven't
proved their worth. Of course it's true that if version 1 of a language does
80% of what's needed, you may well need to double the language size to get
to 90%. That's particularly true for the function library. You can't add
date-and-time handling without adding a lot of pages to the spec, but people
really do need date-and-time handling.

I also think that most of the extra detail in the specification was needed:
not all of it, but certainly most. To take an example, the specification
size for xsl:number is a little more than twice the length in 2.0, although
there has been very little change in the functionality; I would claim that
all the extra text in the specification has been added because the 1.0
specification left too many edge cases underspecified. In fact, the XSLT 2.0
specification is roughly four times the length of the XSLT 1.0
specification, and I think it's fair to say that it has doubled once because
the language itself has doubled, and has doubled again because the language
is much more rigorously specified.

In some cases the increase in length is caused by an attempt to increase
clarity rather than increasing rigour. For example the XSLT 1.0
specification of attribute sets is complete and correct, but so terse that
it is almost impossible to understand the behaviour of edge cases.

To take yet another example, the specification of format-number() is now
self-contained, whereas previously it was defined by reference to the JDK
1.1 specification, which (a) was itself woefully incomplete, and (b) is now
almost unobtainable. The change has led to a roughly threefold increase in
the length of the relevant section in the specification (with no significant
change in functionality), but I think this is universally accepted as being
an improvement. 

The tenfold increase in the size of the XPath specification is harder to
justify (and I'm not sure which specs you are taking into account: do they
include the data model and the functions and operators?). But it's worth
pointing out that the brevity of the XPath 1.0 specification has led to some
profoundly incorrect interpretations, for example a widespread myth that an
XPath 1.0 expression could only access a single document. It's also heavily
reliant on consensus interpretation. For example the entire specification of
the contains() function is: "The contains function returns true if the first
argument string contains the second argument string, and otherwise returns
false." So does "" contain ""? Does "abc" contain "ac"? The reader is left
to decide. In nearly all cases, the vast majority of readers have
interpreted the spec the same way, but there has been a steady trickle of
challenges of the form "the specification doesn't actually say that the sum
of an empty set is zero, so why should we assume that this is intended,
especially as this is not the case in SQL?". In XPath 2.0 the WG was much
more keen to leave no room for doubt.

Michael Kay