[
Lists Home |
Date Index |
Thread Index
]
Hi Eric,
[Dare, question for you at the bottom...]
>> Which of the requirements don't you agree with? Do you have
>> requirements that aren't or can't be met using extensions to XPath
>> 1.0 (e.g. for conditional expressions in XPath)?
>
> Basically the requirement I don't agree with is that it needs to be
> a basis for XQuery and become strongly typed.
OK. I agree about the strong typing. I'm not sure about the XQuery
side, because I think it makes sense for both XQuery and XSLT to use
the same basic data model and the same syntax for e.g. location paths.
But I do agree that the overlap between XPath-for-XSLT and
XPath-for-XQuery could and should be substantially less (I had an
analogy of XPath 2.0 and a stomach-bursting Alien -- killing its
"host" language).
The kind of model I favour is one where XPath is broken down into
modules that can be combined when XPath is used in XQuery, XSLT, W3C
XML Schema, XForms, XPointer, user-defined languages and so on. The
most basic module would support only the basic axes, for example;
other modules would build on top of it to add the support required for
the other languages' uses of XPath.
> I don't want to sound negative, but I don't remember any of the
> comments I have ever done to a W3C WG having ever been taken into
> account in a positive way.
Yeah. I guess that it's my poor memory that makes me think that making
comments is worthwhile (a bit like how my poor memory enables me to
answer the same question on Muenchian grouping over and over again).
>> Another thing we could try is to have a switch that makes XSLT 2.0
>> use XPath 1.0. XSLT 2.0 has some really useful stuff (multiple
>> output documents, grouping, result-tree-fragments out the window,
>> user-defined functions) so it'd be a real shame if we couldn't use
>> them just because we wanted to avoid XPath 2.0.
>
> If you say so I trust you that XSLT 2.0 must be a good thing! I'd
> note though that the features you're mentioning are already
> implemented through exslt. Having them as standard XSLT features
> would be great but only if the price to pay can be lowered!
Grouping isn't supported in EXSLT -- but of course you *can* do
grouping in XSLT 1.0 if you're prepared to jump through the Muenchian
hoops. (Poor Steve; he thought that his name would stop being used...)
I'm also concerned that the XSLT processor implementers will move on
to 2.0 and won't support new EXSLT extensions that mirror
functionality found in XPath/XSLT 2.0. For example, it wouldn't
surprise me if Mike dropped support for func:function in versions of
Saxon that support XSLT 2.0.
But yes, maybe you're right that the benefits aren't great enough to
outweigh the costs, at least for us. Maybe I should just start viewing
XPath/XSLT 2.0 as a specialist language that is only worthwhile for
users who want to use W3C XML Schema and XSLT.
> Another concern I have is that I am not sure that it would be
> quickly implemented and deploied in the major web browsers. Of
> course I can't tell since I am not part of W3C, but do you have any
> commitment from Microsoft about this?
(Coo, don't *I* feel important!) I have no idea; I've only been an
invited expert for a few days. We should ask Dare.
Dare, is Microsoft committed to quickly implementing and deploying
XPath/XSLT 2.0 in IE?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
