[
Lists Home |
Date Index |
Thread Index
]
At 11:13 AM 12/24/2001 -0800, Jeff Greif wrote:
>One issue not addressed is what progress has the XQuery WG already made on
>update syntax. If they have already done substantial preliminary work, but
>have some perceived need to produce an interim XQuery spec before that's
>ready for release, it may be a duplication/fragmentation of effort to
>produce a competing spec in an Oasis TC, and take just as long.
In fact, this is just the case. Several members of the XML Query WG
developed a proposal, and several vendors are implementing variations of
this proposal. This proposal was the basis of a presentation that I gave at
XML 2001 in Orlando this Fall.
Whatever we release in XQuery 1.0, it has to be as solid as possible. That
means leaving out features that we don't think we have given adequate
review or for which there are not enough implementations. If you look
carefully at the entire set of XQuery 1.0 specifications, you will see that
there is a *lot* of technical content, and we have to make sure that it is
well-specified and consistent across the specifications. Coordination
between XQuery and XPath also takes time.
For me personally, updates are an extremely high priority. I am concerned
about the likelihood that several similar implementations may hit the
market before there is a standard for updates. But I am also very concerned
that XQuery 1.0 be released relatively soon.
So would you still want to see updates in XQuery 1.0 if it meant releasing
XQuery six months later?
Incidentally, given the need for a well-specified proposal that is solidly
integrated with XQuery, and given the fact that the existing proposal came
from members of the XML Query Working Group, I doubt that doing this work
outside the W3C would really save time. I also doubt that disallowing
XQuery features like element constructors would save much time, and I think
that it is important to be able to construct new instances in updates so
that they can be inserted or used to replace existing content.
Jonathan
|