[Bug 26958] On not precluding updates in XQuery 3.1

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

--- Comment #23 from Jonathan Robie <jonathan.robie@gmail.com> ---
Back to the comment that reopened this issue.

(In reply to Michael Kay from comment #14)
> I do not want F+O discussions of operators such as map:merge to contain any
> mention of concepts like "copying" a map or array. It's a meaningless
> concept at that level. 

I think map:merge and map:remove are already quite clear.

As comment #13 points out, this is not clear for the values of map constructors
and array constructors. Comment #13 says how this should be clarified.

I believe the same clarifications need to be made for functions that create
maps in which a map or an array is the value of a key/value pair - that's the
only clarification that is needed.

> Specs should be testable, and there is no way of
> testing whether map:merge has copied a map or array or not, therefore the
> spec should have nothing to say on the subject. Any discussion of
> identity-based semantics for maps and arrays must be confined solely to the
> Update specs, plus if necessary a permissive enabling statement in the data
> model to legitimize it.

In an implementation that does not persist maps and arrays, these assertions
are not testable, and will not be even with the update specification.  So this
does not impede any optimization for such an implementation.

In an implementation that does persist maps and arrays, this clarifies the
semantics of what it means to do an in-situ update that is analogous to in-situ
updates for XML. Any implementation that persists instances between now and the
release of the update specification needs to get this right, now, or else
reconstruct all data once we clarify the answer.

The XQuery / XPath 3.1 specifications have three requirements:

1. For the sake of optimizability, a map SHOULD NOT expose identity
   via the is, <<, >>, union, intersect, or except operators, or any
   operation that exposes document order.

2. The map feature MUST NOT preclude in-situ updates analogous to
   updates in the XQuery Update Facility.

3. Arrays MUST NOT preclude in-situ updates analogous to updates in
   the XQuery Update Facility.

The ambiguity we are discussing means that #2 and #3 are not met for data
created by these specifications and then persisted. This will affect primarily
implementations interested in persisting JSON, and being able to update it in
the future. People are doing this now, at least with JSONiq, and will
presumably do the same with XQuery 3.1.

We can make sure we got it right by (1) imagining that the 'is' operator is
available for maps and arrays, and making sure that we understand what the
result would be, or (2) imagining that an in-situ update is made, and making
sure that the result is clear. 

If you insist that all assertions must be testable in this version of the
specification, we could (a) relax the SHOULD NOT requirement so that the 'is'
operator is available to make the assertions testable and we can meet our MUST
NOT requirements, or (b) discuss how to manage the progression of our documents
so that we're not inviting people to persist data created with our
specifications without being clear what happens if it is updated.  But I think
both of these are costly options, and I don't think it's costly to be clear in
our current specifications.

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

Received on Wednesday, 5 November 2014 16:16:43 UTC