Conclusion

In this chapter we have looked at the relation between XQuery and XSLT (and their common subset, XPath) from a number of perspectives. We began with an analysis of the areas of similarity and difference between the two languages and the reasons why the differences occur. We saw that although there are large areas of overlapping functionality, significant differences exist in the requirements that the two languages were designed to meet, and that we can trace many of the design differences to the fact that the two languages were intended to be used in different environments. Other differences, however, reflect the different cultures of the document world, with its SGML history, and the database world, with its traditions based on SQL. Perhaps the most significant difference is that XSLT is stronger at handling loosely structured data, while XQuery is strongest at handling data that is highly regular. This in turn accounts for the different emphasis in the two communities on schemas and type systems ”though as we saw, the languages are converging here, with better facilities in XSLT to handle strongly typed data, and better facilities in XQuery to handle semi-structured information.

Then we looked at the state of the art in XSLT optimization, with the aim of understanding the extent to which the lessons learned from three years of XSLT experience are applicable to XQuery. In my view, many of the techniques that are used by XSLT optimizers will be equally applicable to XQuery processors, in particular techniques such as pipelining, lazy evaluation, expression rewriting, and avoiding sorts in path expressions. XQuery environments, however, will present additional challenges and additional opportunities for their optimizers, because they will generally be working on databases that have a choice of indexed access paths available. In database work, the key task of an optimizer is to identify the indexes that enable the query to be evaluated without sequential searching. XQuery implementers will bring a wide range of experience to this task from the relational world. But we saw that one risk in this is that the heavy emphasis on join optimization may prove less important in the XML world. This depends greatly on the types of applications that XML databases end up being used for, which is difficult to predict at this stage in the game.

The fact that XQuery and XSLT share a common data model, and in XPath a common sublanguage, is a major achievement by the W3C, given the diverse backgrounds of the two working groups. I believe that it will also be a major benefit to users. It will reduce learning curves because so much is common to the two languages. It will also enable the two technologies to be used in complementary roles; for example, it becomes very easy to present the result of an XQuery using an XSLT stylesheet. And I suspect ”only time will tell if I am right ”that many implementers will be able to reuse the same run-time engines to implement both languages, which will obviously benefit both user communities. ^[9]

^[9] Since writing this, I have fulfilled my own prediction. The latest release of Saxon does just this.