[
Lists Home |
Date Index |
Thread Index
]
Jonathan Borden favoured:
>
> 3) updating XSLT including XPath 2.0 as the XML syntax 'version' of
XQuery,
> that is to say any features of XQuery not included in XPath
> 2.0 should be included in XSLT 2.0 (well it already has element
> constructors etc). Is this feasable?
Interesting question.
Certainly XSLT and XQuery are converging, functionally and to some extent
(by virtue of XPath 2.0) syntactically. I think this is good, both for
implementors and for users, and it is quite legitimate to ask how far this
convergence can be taken.
It remains true that the primary areas of application (tranformation versus
query) are different, and this imposes some different requirements.
[Unfortunately this sometimes gets obscured by an argument that XSLT is more
about documents, and XQuery is more about data - I think that argument is
completely spurious. Transformation and query are both operations that apply
equally to documents and to data, and the fact that XSLT has historically
been stronger on documents, while XQuery has been stronger on data, is an
accident of history that needs to be corrected.]
There are features in XSLT that should never be included in XQuery, notably
template rules - because they are needed specifically for transformation,
and because they are impossible to optimize. I find it hard to identify any
functionality in XQuery that should never be included in XSLT, with the
possible exception of update. In fact, I think there is very little
functionality in XQuery 1.0 that is not present, in some form, in XSLT 2.0,
except perhaps for strong type checking - though we will be doing more work
on typing before XSLT 2.0 is finished, using the work done by the XQuery
group as our input.
I don't see the processing model of XSLT changing fundamentally - that is,
it will produce a set of result trees from a set of source trees, with the
source documents being left unchanged by the process. It's an interesting
question whether this process can be leveraged to do updates. I suspect it
can, by some kind of containing application that uses XSLT to do a
transformation, and then substitutes the result tree into the database that
contained the source documents. I think this might be what Evan is trying to
achieve with his TransQuery. The practicality of this, of course, depends on
someone producing an XSLT processor that is engineered to work efficiently
with large databases, which is not a trivial task; and the usability will
probably not be as good as a purpose-designed update extension to XQuery,
except in simple use cases like that of replacing a single document within a
database.
Mike Kay
Software AG
|
