[
Lists Home |
Date Index |
Thread Index
]
Hi Roger,
> 1. XPath 2.0 replicates nearly all the functionality of XSLT.
Well, XPath 2.0 doesn't provide mechanisms for creating nodes or
defining functions, for grouping, for sorting and so on. If by "nearly
all" you mean "a few pieces of", then OK.
> Thus, we see that there is a good bit of redundancy in the
> XSLT/XPath 2.0. [Such redundancy increases the size and complexity
> of the language, without additional functionality.]
I agree. The argument for the redundancy is that XPath 2.0 needs to be
usable alone as a query language (for simple queries returning
existing nodes). Personally, I wish that the XPath used in XSLT 2.0
was a subset of XPath 2.0, thereby reducing the redundancy. On the
other hand, sometimes it's useful to have simpler ways to do simple
tasks: the if expression is so much more compact than an equivalent
<xsl:choose> (similar to the way that many programming languages have
short conditional expressions and longer if/elseif/else expressions).
> 2. XQuery uses (hosts) XPath 2.0, and adds additional functionality.
> That is, XQuery = XPath 2.0 + more functionality.
It's also true to say that XSLT 2.0 uses (hosts) XPath 2.0 and adds
additional functionality. That's the purpose of a host language.
> Although I have not made an exhaustive comparison, it would appear
> that the functionality that XQuery provides is a superset of that
> provided by XSLT.
I think you've got that the wrong way round, but don't take my word
for it: go ahead and make that exhaustive comparison. Try, for
example, to find XQuery equivalents for XSLT's <xsl:analyze-string>
and parsed-text(), for format-date() and format-number(), for keys, or
for <xsl:for-each-group>.
> Is the intent of the W3 to deprecate (i.e., eliminate) XSLT once
> XQuery is released?
I doubt the W3C would have spent all this time working on XSLT 2.0 if
it was going to deprecate it as soon as it was released.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
