The XPath/XQuery juggernaut (Was: limits of the generic)
Lists Home |
Date Index |
In a message dated 01/10/2002 11:48:08 GMT Daylight Time, firstname.lastname@example.org writes:
> So far, I've just resigned myself to ignoring XPath 2.0, XSLT 2.0
> and XQuery.
Back with the first release I thought "this design is just dreadful,
but they're just the first WDs, and James Clark is in the WG; he'll
make sure it isn't totally screwed up". Then he left. Then on the next
release I thought "this design is just dreadful, but they're just the
second WDs, and Mike Kay is in the WG; he'll make sure it isn't
totally screwed up".
Now we're on the third or fourth WD (depending on the spec), heading
rapidly for Last Call, and I wish I'd raised more of my concerns, more
loudly, earlier in the process. I don't want to see a pair of
languages that I loved for their elegance and simplicity turned into
the monsters that they're becoming. But I'm just one, easily ignored
voice, without a big corporation behind me and without either James
Clark's or Mike Kay's authority. Now I'm an invited expert on the WG I
can argue, I can vote, I can register dissent, but I doubt that any of
that will turn this juggernaut around.
XSLT and XPath users of the world, unite! The WGs will take your
silence as approval, not disgust. Send your comments to
email@example.com. It doesn't matter if you don't have a
solution to all of XPath's woes -- the WGs are there to create the
solutions -- but it does matter if you think the languages are off
track, especially if that means you're not going to use them. None of
us want XPath/XSLT 2.0 to turn into another W3C XML Schema or XLink.
Congratulations on joining the juggernaut. :)
I suspect it is far too late for you to have any tangible effect on XPath 2.0/XSLT 2.0/XQuery 1.0 but would be delighted to be proved wrong.
Increasingly, as I observe W3C process from the outside the "black box" which sets the juggernaut for any particular technology going happens outside the public gaze yet seems of great importance in setting the foundations of the embryonic technology. I am referring to the definition of a Requirements Working Draft.
To the best of my knowledge the community for a technology is, in reality, not consulted in the development of a Requirements document - other than the arguable figleaf of "the community" who also happen to be W3C members.
Discounting SMIL, the XPath 2.0 and XSLT 2.0 specifications are arguably the first XML-based W3C technology which is well in process to reach version 2.0. The failure (to the best of my knowledge) of W3C to consult the XSLT/XPath community is a significant failure of W3C process, in my view. It may not be a failure in "W3C Process" but I suggest that that document be revisited and revised in the light of the need to consult an existing technology community.
Specifically, I would propose that the community be consulted at the stage that a Requirements document is first being considered.
It isn't impossible for a WG developing a complex technology to consult and respond to a developing user community. The SVG 1.0 REC demonstrates that consultation and response to that consultation is possible. Many requests from the SVG community were fed in to the W3C and, at the risk of generalising, have appeared in the Requirements documents for SVG 1.1, 1.2 and 2.0. In my view, the SVG process contrasts profoundly with the frustrating fig leaf consultations about W3C XML Schema and XPath 2.0/XSLT 2.0/XQuery 1.0 which took place last year (or was it the year before?) and earlier this year on XML-Dev.
Another facet of the SVG process that usefully bears comparison with the XPath/XSLT/XQuery process is that the Chairman and Editor(s) of the SVG specs interacted (usually) promptly and frankly with the community. In fact, they were in effect part of the community. Apart from the notable work done by Michael Kay, as an author and on XSL-List, can such involvement be claimed for XPath/XSLT/XQuery? It seems to me that involvement can make the difference between WG members being in touch with a community or being out of touch.
The more scrutiny that W3C specs receive at early stages of development the better. When frustrating pseudo-consultations become the norm, the W3C can't be surprised when those who might usefully comment choose to make better use of their time than provide input which will be ignored.
Hopefully Liam will recognise the need for version 2 and later of XML specs to authentically consult the relevant user communities.