[
Lists Home |
Date Index |
Thread Index
]
Don,
I suspect you are right - companies strongly prefer to release based on
recommendations, and generally not on working drafts. And since most
representatives on the XQuery WG has an implementation of XQuery that
they want to get out, we want to be done. But first we have to become a
Candidate Recommendation, prove that there are interoperable
implementations, then become a Proposed Rec, then a Rec. I think that
will take a year. In the meantime, there's quite a few vendors who need
to figure out how to cope - do we release something based on a CR or a
PR draft?
I don't think that any company has been intentionally holding up the
XQuery spec. That suspicion seems to be stronger among people who have
not attended Working Group meetings than those who are members.
Quilt was largely done by May, 2000, and was submitted to the Working
Group in September, 2000. By that time, we had done the hard work of
agreeing on our requirements. So what have we been doing for the last 4
years?
1. Real innovation. Quilt was loosely typed. XQuery can be statically
typed, or an implementation can use only dynamic typing. The data that
is queried may also have a range of typing, and we've had to keep both
traditional document mungers and traditional database people happy,
since XML completely blurs the old distinctions between documents and
data. I would say that we've done a solid year of real innovation and
trying out alternatives, and a lot of this has been in the area of typing.
2. Syntax issues. The mix of an XML syntax for construction with a
keyword syntax for operations is intuitive for users, but has required a
lot of work on the grammar side.
3. Compatibility with existing complex standards. XPath is more complex
than what XQuery would ideally use for path expressions, XML Schema is
more complex than what XQuery would ideally use for a type system,
namespaces are more complex than what XQuery would ideally use for
identifiers, the semantics of some datatypes in XML Schema had not been
adequately specified for a language that adds operational semantics,
whitespace rules in XML introduce additional complexities...and beyond
that, our cooperation with other Working Groups has cost very
significant time. I would guess that compatibility with XPath has cost
us easily a year - and involved merging two Working Groups.
Compatibility with XML Schema is part of the work on types that I
discussed above, but also took a year. Namespaces and whitespace took
less than a year, but definitely considerable time.
4. Inefficiencies and trying to invent our own process. The W3C process
was not really designed for specs as complex as XQuery, and we've lost a
lot of time just trying to deal with the amount of feedback we receive
and the huge amount of internal traffic from the member companies, who
are implementing XQuery. One thing we learned, for instance, is that
XQuery needs three chairs, not just one. We've also made a bunch of
other changes in the way we process issues to speed things up.
It's easier to work quickly when any of the following are true:
- Nobody cares about what you are doing, so one to three people can
create the solution that looks right to them. (e.g. Quilt)
- There's not a lot of prior work that you have to be compatible with.
- There's a lot of prior art that solves just exactly the problem you
want to solve, so it's mainly just shuffling the syntax around.
- There's a homogeneous user community, so you can attend to just their
needs (e.g. just relational users, or just document users in the
humanities).
- You don't have to prove interoperable implementations.
- You're allowed to just ignore public comments you don't agree with.
- All implementations operate in the same environment, and look fairly
similar.
- It's a small, simple problem.
As it happens, none of this is true for XQuery.
Jonathan
|
