[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote:
> ... All it takes is one
> <xsl:element name="{substring(.,2,5)}"> (or its Xquery equivalent)
> and you haven't a hope of figuring out any more specific type for
> the result than "element" you can't tell what element it is never mind
> if it is valid to use such an element at that point in any possible
> result tree that might be constructed.
>
Yup. Of course the above is similar to a C++ style
(foo) cast. The only proper response is that the range of the
"substring" function is not limited to the required element names
i.e. the constructed element might be anything, hence use
of such a function might cause the 'static validation' to fail.
On the other hand, if the types were constructed using proper
regular expressions (in this case for strings) and if the type
system understood the "substring" function then yes it is possible
that such a 'static validation' would succeed.
That is to say, just because XQuery might enable something,
it doesn't imply that such enabling would be without cost --
which is ultimately what this debate is weighing.
My own feeling is that XSLT 1.0/XPath 1.0 are good enough
such that folks who want to avoid the overhead of XPath2/XQuery
can indeed do that -- just use XPath 1.0/XSLT 1.0 -- people
should resist the temptation to 'upgrade' to the latest
version number just because it exists
(writing from an NT4.0 box, and perfectly happy doing so)
Jonathan
|
