[xquery-talk] XQuery Platform Support

Michael Kay mhk at mhk.me.uk
Mon Oct 20 10:02:31 PDT 2003


> > But in terms of functionality, XSLT 2.0 is richer than XQuery 1.0.
> 
> !? I was left with the impression the two languages have 
> equivalent expressive power. 

Both languages are computationally complete, so in that sense they have
equivalent expressive power. The differences are in terms of use cases
that can be done easily in one language and cannot be done easily in the
other.

The only constructs in XQuery that don't translate trivially into XSLT
2.0, as far as I am aware, are:

(a) order by (ability to sort a tuple stream, rather than just a
sequence)
(b) separately-compilable modules

> Could you detail please  ? What 
> would be an example of a query that can be expressed in XSLT 
> 2.0 and cannot be expressed in Xquery 1.0 ?
> 

Constructs in XSLT 2.0 that don't translate trivially into XQuery
include:

(a) template rules
(b) attribute sets
(c) analyze-string
(d) for-each-group
(e) keys
(f) format-number
(g) format-date
(h) unparsed-text
(i) multiple result documents
(j) serialization control
(k) import precedence

Most of these features are appropriate to a transformation (and
rendition) language and are not appropriate to a query language. This is
why I advise people to use XQuery for database query and XSLT for
document transformation (including for rendering the results of a
query). You asked for an example of a "query" that can be expressed in
XSLT 2.0 but not in XQuery 1.0: that's the wrong question, because XSLT
2.0 is not designed to express queries.

> Moreover, I know at least 10 relatively good implementations 
> of Xquery 1.0 but I am
> not aware of so many XSLT 2.0 implementations (if any).
> 
There are about 20 XSLT 1.0 processors around, but only three XSLT 2.0
processors that I know of (one of which has not yet shipped). I think
this is an inevitable consequence of the fact that it is a 2.0 spec: for
most 1.0 vendors, it makes sense to hold back until the 2.0 specs are
completely stable. I suspect there will never be more than five or six
XSLT 2.0 implementations, because the weaker products will drop out of
the race, and because commercial vendors can't see how to make money
competing against open source offerings. Five is plenty to give users an
effective choice.

Of course my advice to someone planning a production application about
the risks of building it on XQuery 1.0 apply equally to XSLT 2.0. The
stable risk-free platform that's available today is XSLT 1.0.

Michael Kay



More information about the talk mailing list