W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2014

[Bug 26958] On not precluding updates in XQuery 3.1

From: <bugzilla@jessica.w3.org>
Date: Tue, 11 Nov 2014 13:42:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-26958-523-ebzIIlNlN9@http.www.w3.org/Bugs/Public/>

--- Comment #29 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to Michael Kay from comment #28)

> Perhaps we have a different understanding of the word preclude?
> My understanding is it means "to make impossible". The requirement is that
> we shall not do anything that makes updates impossible. I think we can
> achieve this by doing nothing. Your objection, going back to the original
> comment in this bug entry, is that doing nothing "results in two sets of
> behavior that can be distinguished only when updates are implemented". I
> don't think that's a problem; the time to define the detail of how updates
> work is when we design the update facility, not now. 

My objection is that:

1. People are creating persistent data now, and there's a big gotcha if we're
going to tell them later that they created it the wrong way and it cannot be
updated according to our specs.

2. There are already implementations that update JSON from an XQuery
environment. Like the original update spec, implementation is happening before
the specification because we are lagging on the spec.  People need some

3. We know what an in-situ update is.  We have a requirement to not preclude
it. We have a working group decision on how to do this.

> Many people (for
> example, most XPath/XSLT implementors) will never implement in-situ update,
> and it would be entirely wrong for specs other than the Update spec to
> attempt to dictate choices that have no effect on non-Update programs.

This has absolutely no effect on an implementation that never implements
in-situ updates.  But it still affects the non-update specs, just as XML
constructors do.  For XML constructors, we carefully spell out what is
constructed so that updates can be done consistently.

In fact, the basic question is this: should our constructors clearly state what
is constructed or not?  For updates, it's important to do that, because
otherwise we do not know what is being updated.  You seem to be taking the
position that we don't need to be clear about this because it's only a gotcha
if someone tries to update it.

This is essential for any implementation that does in-situ updates.  It has no
effect on any other implementation.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 11 November 2014 13:42:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:51 UTC