[Bug 26958] On not precluding updates in XQuery 3.1

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26958

--- Comment #17 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to Michael Kay from comment #15)
> If I could also add what is intended as a constructive remark on the
> original subject of this bug report ("not precluding updates") I think it
> would be very helpful if we had a concrete description of what kind of thing
> it is that we are intending not to preclude. 

I assume that this is a response to comment #13, but I can't tell what part of
comment #13 you are objecting to.

We intend not to preclude in-situ updates of deeply nested structures using an
extension of the update specification.  We want to specify the results of these
updates as clearly as the examples in comment #16.

One example of this is shown in the use cases - the internal version shows it
at
www.w3.org/XML/Group/qtspecs/requirements/xquery-31/html/Overview.html#update.example

And we want to be able to do this for deeply nested structures, using the basic
model of the update spec: identify a target for the update with an expression,
identify the update operation, the operation is placed on a pending update
list.

> It's become clear in recent
> weeks as we have discussed different models of trees and graphs that there
> are many different possibilities of what might happen once you allow maps to
> be both mutable and refernceable, and it seems that people are happy to
> preclude some of these models and not others. 

I don't know if you were able to listen in to any of the face-to-face
discussion on this point on the phone at the face-to-face, but comment #13 was
the result of a relatively long discussion on this question.

We do need to make design decisions. Every design decision preculudes some
possibilities. But we tried to keep this relatively open.

> So I would suggest (again) that the best way of not precluding any
> particular future development is to say nothing until we have designed and
> reached consensus on that future developement. Otherwise we're being asked
> to sign a blank cheque. 

I really do not think that comment #13 amounts to a blank check.  I wish you
could have been there for the entire discussion that led to this decision.

> Just as we're being told that agreeing to the
> requirements document saying that we "would not preclude updates" means we
> have to put something in the data model, we are then going to be told that a
> carefully muted form of words in the data model means we agreed to some
> particular kind of database system becoming within the scope of our specs.

I think that's equivalent to precluding updates on nested maps and arrays.

We had to specify that element constructors create new copies of nodes
precisely to be clear on the kinds of update semantics that we're discussing
here.  And we also need to specify whether they create new copies of maps or
arrays if we want to be able to support interoperable updates.

> If we had a concrete proposal on the table for a spec that involved
> updateable maps and arrays, we would at least have some idea of what we are
> trying not to preclude.

I hope we do not need a complete proposal for the 3.1 update specification
before our current 3.1 specifications are allowed to progress.

I had thought this was relatively clear:

We want to do in-situ updates using the same basic model that the update
specification uses for nodes: identify a target for the update with an
expression, identify the update operation, the operation is placed on a pending
update list.

That means that we need clarity on when map and array constructors or functions
are creating copies, because otherwise we can not specify the effects of
updating a map or array.

What else do you believe needs to be specified to have sufficient clarity to
progress?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 4 November 2014 21:28:06 UTC