|
|
Re: [xml-dev] Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
|
[
Lists Home |
Date Index |
Thread Index
]
In a message dated 08/05/2003 16:05:53 GMT Daylight Time, michael.h.kay@ntlworld.com writes:
I also think that the "defence of hard-won consensus" is the only way to
prevent committee-run projects taking an infinite length of time.
Michael,
In this case there may be another approach which would avoid the "infinite length of time" scenario. In fact, it might even produce more timely results.
I have to admit that this formulation is not fully thought out, but might it "work"? Might it, when all is said and done, be the "least bad option"? Or to put it another way, who would shout loudest if it was implemented?
What is in my mind, in a pretty primitive form, would be to split off XQuery and let it do its own (fully typed, PSVI-based) thing. You indicated that there is real push from the XQuery camp for it be completed "yesterday". Since XPath 2.0 (as was?) is a subset of XQuery 1.0 that wouldn't slow down the XQuery people - just stop referring to the subset as anything (the subset wouldn't be XPath any more) - the XQuery camp could continue on and finish XQuery in their own time to their own specification.
What I wonder about for XSLT 2.0 / XPath 2.0 is to take the current specs back to the drawing board, in a sense similar to what XSLT 1.0 did relative to DSSSL, and produce a non-typed XML Query/Transformation language. Alternatively to produce a nicely layered XML query/transformation language - allowing typing or not as the case may be.
Conveniently / coincidentally I note that Saxon 7.5 doesn't yet implement the validation and type stuff. Some would say that would be a very appropriate place to stop. :)
After they recover from any initial shock, I can see the XQuery camp being content with such a proposal (since they can get on and finish their spec) and the anti-typing XSLT/XPath camp too (since they will get either an untyped spec or a well-layered implementation of typing).
So, put simply, XQuery 1.0 is a typed XML query language, and a revamped XSLT 2.0 / XPath 2.0 is an untyped (or well-layered) XML query / transformation language.
The problem, and it might be a big problem, would be those who want / think they need typing in XSLT 2.0. Perhaps you are among that number.
I have looked back at the XSLT 2.0 Requirements document and the case made for including W3C XML Schema as a "Must" was pretty thin. In fact the drafting of 3. in XSLT 2.0 Requirements has never been finished.
What are the strongest arguments in favour of strong typing in XSLT 2.0? Who is pushing those arguments?
The proposal is:
1. Split XQuery from XSLT 2.0 and XPath 2.0
2. XQuery would proceed to Recommendation as a fully-typed, PSVI-based XML query language, meeting the needs of database people.
3. XSLT 2.0 and XPath 2.0 would be reviewed following separation from further XQuery development -either to provide a non-typed or well-layered typed PSVI-free XML transformation / query language.
This would allow a language, XQuery, to be created suited to the needs of those who want typing and PSVI. Separately, XSLT 2.0 NG / XPath 2.0 NG could provide either an untyped or well-layered XML query/transformation language. Those (few?) in the XSLT community who feel that typing in XSLT is needed could either move to XQuery to get the perceived advantages of typing and PSVI, or stay with XSLT to help provide an untyped or a well-layered typed XSLT 2.0, which can be used by those who don't want the PSVI.
Controversial, I guess but would that be worse than what may lie a few months down the track?
Andrew Watt
|
|
|
|
|
|