[
Lists Home |
Date Index |
Thread Index
]
> Standards should be based on existing practice;
> failing that, there should be ample opportunity for designs to compete.
Absolutely. This is, and always has been the crux of the problem with XQuery
and company. Yes, in XML we've become used to "standardization" committees
that are really research teams, and this is not always bad. We've had some
good stuff such as XPath 1.0 emerge, and it actually worked out in the
marketplace. Nevertheless, I think it would have been silly to think that
XPath atomatically became the sine qua non of simple XML expression languages
back in November, 1999. The fact that I'd scoff at an XPath alternative now,
(or an XML alternative, for that matter) is because I've seen them succeed in
the broad marketplace for me and others.
Along comes WXS, invented by committee, and not so much a success in the
marketplace. People have come to expect that WXS will have competitors, and
that a significant bdy of practitioners will simply cease to be concerned with
the continuing development of WXS. I can understand that memebers of the WXS
WGs might be defensive about this, but such defensiveness is unwonted. Afer
all, I'd be considered a whiner if complained that people chose other
software for their XML processing than the software I work on. But you say
"that's just a product, not a standard, which is supposed to provide cohesion
between products". I'd counter that any time a standardization committee sets
out to invent pratice rather than standardize on existing practice, that they
are actually productizing and should be subject to the same market dicipline
as product developers.
So here is XQuery. They insist on building on foundations (WXS and Infoset)
which are not clear winners, and brush off the fact that many have decided not
to have anything to do with these foundation stones and thus are not ikely to
have anything to do with XQuery. Some of us have railed against XQuery in
general, and XQuery group members, as I can understand, get defensive and
complain that we're not being part of the process of building and improving
XQuery. But I am astonished that we should be expected to be so. To many of
us XQuery and family are so fundamentally flawed that there is no visible path
to remedy. But that should be OK. XQuery is the way it is because many feel
that it solves their needs, and that of their customers as they've invented
it. Fair enough, but many of us disagree, and I've predicted that whatever
else happens, XQuery is going to be subject to the same market discipline as
WXS.
Speaking for myself, I have very little energy available for all non-paying
work in this area, so rather than going through what I think is a time-wasting
exercise of reading that towering stack of material and bending my brain until
I actually understand it well enough to provide coherent comments, that I'd
rather work on a much simpler alternative. I think this POV is borne out by
responses such as that of Mike Kay to those who say the entire edifice of
baked-in types should be rethought from scratch. Clearly, if Mike Kay is one
of the committee members closer to our thinking than others, and if he's also
one of the ore publically engaged, and he has the defensive shell on to the
idea of fundamental reworking, then we might as well save our breath trying to
get the WG to make XQuery and co compatible with our needs.
Personally, I think the W3C should have a process step that says: we're
inventing too much stuff here, and it seems there are too many competing
approaches out there. We should put this work aside for some time to allow
practice to develop more thoroughly.
Everyone lauds standards by comparison to preceeding, chaotic days when
vendors competed ruthlessly with incompatible technologies, forgetting that
the key to the success of the eventual standard lay in that very ugly
competition.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Is XQuery an omni-tool? - http://www.adtmag.com/article.asp?id=7620
Gems From the [Python/XML] Archives - http://www.xml.com/pub/a/2003/04/09/py-xm
l.html
Introducing N-Triples - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk17/index.html
EXSLT by example - http://www-106.ibm.com/developerworks/library/x-exslt.html
|
