|
|
Re: [xml-dev] Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
|
[
Lists Home |
Date Index |
Thread Index
]
In a message dated 11/05/2003 20:20:14 GMT Daylight Time, liam@w3.org writes:
I suspect it's a matter of timing. The Working Group is concentrating
hard on getting the primary documents published.
Tutorials need to be written based on final documents.
Hi Liam,
I can understand that issue of timing. But that wouldn't hinder a commitment in principle to provide a primer later, would it?
For XML Query, you'll find some good examples in the Use Cases document.
Absolutely.
Is it possible to feed into the W3C system the suggestion that Use Cases should be a routine early step for all proposed specs? I feed the idea of Use Cases in on an ad hoc basis. Some WGs seem very receptive. Others are less so.
One big advantage of Use Cases is that a semi-outsider can use them to read into the mindset of a WG early in the process. Before an approach is set in stone. At that early stage it can be much easier for an outsider to see gaps in Use Cases than in a Requirements document. YMMV.
I, for one, appreciate the usefulness of the Use Cases for XQuery.
XML Query seems to me to have been improving steadily over the past
two years or so,
I think they are significantly better or less bad - I guess it depends on your viewpoint. :)
and in particular is now much more closely aligned
with the way W3C XML Schema types and validation work. I should
probably add that this doesn't preclude something like relax-ng
validation in a future version -- only the basic type system is wired
in, and if you're going to have a type system, it does seem to make
some sense to build it on other type systems in use with XML.
People here complaining about Schema support should note that it's
optional: the Basic Conformance Level of XML Query doesn't require it.
It's not quite so simple as that.
I don't want to over emphasise the difficulties but there are little issues like this, which was brought up on XSL-List today:
concat("some string", position(), ".html")
which needs an explicit cast on position() to avoid a type error. No big deal if you have spent time with the specs, but a little surprise for someone migrating from XPath 1.0 who expects not to need to learn about XSD types.
Users also don't have to worry about it. If you want to get the
benefits (colour all links red, and all headings blue, find me all
dates between these ranges used in changelog entries and make an
RSS feed, find all elements derived from CorporateTypes-phoneNumber and
check they don't contain our old telephone numberextensange prefix), then
you'll be glad of the new features.
If the upgrade pathway from XSLT 1.0 / XSLT 2.0 for existing XSLT users is smooth, I find it difficult to see any reason for staying with XSLT 1.0. The extra functionality in XSLT 2.0 is very attractive.
Just my $0.03.
Andrew Watt
Best,
Liam
|
|
|
|
|
|