[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Inside every fat book is a thin book trying to get out (a
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|