XSLT and XQuery: a difference of culture
Mike Kay from
Software AG gave a high level comparison between XSLT and XQuery at the fourth Forum
XML, where he concluded that the main differences between the two languages were
differences of culture and perspective, but also that XQuery was more ambitious
than XSLT and would require more complex optimizations.
After an
introduction remembering some of the reasons for the success of XML and XSLT, Kay
clearly highlighted that there were more similarities than differences between XSLT and
XQuery:
Like SQL, XQuery and XSLT are both high-level declarative languages based on
abstract data models, both standards and they are both defined in term of simple
operations that can be combined (notion of closure). Unlike SQL, they deal
with hierarchical data structures and the underlying data format (XML) is fully
defined.
At a high
level, their main differences are that while XSLT is a transformation data
language with an interchange centric model, XQuery is a query language with a
storage centric model. Kay sees here a cultural difference between data
oriented and document oriented applications:
Two traditional worlds,
one world which would traditionally have been handled by the BP department and
the other world which would traditionally have been handled by the marketing
department having to be brought together into a single web site, and that was as
much a cultural clash as it is a technology clash.
This
difference of perspectives has already led to significant differences between
the two languages, such as in their relation to XPath: XSLT uses XPath as a
"sublanguage" located in attributes of XML
syntax, while XQuery is constructed as a superset of XPath.
Kay also
predicted that because XQuery is being oriented toward large sets of
XML data, complex optimizations would be required which would push XQuery
implementations out of the scope of individual developers who have developed
efficient open source XSLT implementations, eventually causing XSLT processors
to be considered as a technology available for free. Saying that he would not
feel like writing a XQuery implementation in his spare time as he has done with
the XSLT Saxon processor, Kay said that there would be a better acceptance for
commercial XQuery implementations optimized to run on large sets of data.
Other
stories:
GoXML DB 2.0 has XQuery too. (Matt MacKenzie - 05:38, 28 Nov 2001) http://www.xmlglobal.com Re: XSLT and XQuery: a difference of culture (Eric van der Vlist - 12:38, 25 Nov 2001) > I strongly feel that XSLT 2.0 must allow use of XQuery on equal footing with XPath.
It's a nice idea, but this doesn't seem obvious. XPath has been designed by the XSL Working Group as a sub-language to be used in attributes of well formed XML documents while XQuery is designed as a language as complete as XSLT using a non XML syntax.
Mixing XSLT and XQuery would therefore be a problem both at a semantic and syntaxic level.
Eric
Re: XSLT and XQuery: a difference of culture (Jess Holle - 00:56, 25 Nov 2001) I strongly feel that XSLT 2.0 must allow use of XQuery on equal footing with XPath. This must be via a standard, albeit not required, mechanism and syntax. There are a lot of things one cannot do efficiently in standard XSLT or XPath but should be possible via XQuery. Letting this interface fracture into implementation dependent chaos will hurt us all! Re: XSLT and XQuery: a difference of culture (just another XQuery implementation - 15:19, 23 Nov 2001) www.x-hive.com/xquery |