[Bug 26958] On not precluding updates in XQuery 3.0

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

Ghislain Fourny <g@28.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |g@28.io

--- Comment #5 from Ghislain Fourny <g@28.io> ---
Hi,

First, I think it is very good design that the core (XQuery 3.1) spec does not
expose the identity of maps and arrays (meaning, no query allows a user to
tell).

Second, I agree with Jonathan's point on document stores. When we designed
JSONiq, we precisely had the document store (more precisely, MongoDB) use case
in mind, and therefore used copy semantics in constructors, which considerably
simplifies read/write to the underlying store. In terms of usability, it proved
to be a good decision and I would make the exact same again without hesitation
(for this very use case, of course). The drawback -- but it is the price to pay
to achieve this usability -- is that it is hard to completely optimise copying
away when it is not needed (e.g., when the child is only used once, which
happens quite often in memory).

In general, I feel tension between two visions of the usage of maps and arrays.
These two visions have been on top of our minds, I think, from the beginning of
the design of the 3.1 spec. I believe that this is accurately described by Mike
(network vs. hierarchy). It is important to note that the two corresponding use
cases (1. identity- and type-preserving maps in memory, 2. storage as a
document in a DB) are both equally important and needed by users (I think).

Perhaps the decision could be left to the design of the Update Facility 3.1,
i.e. XQuery 3.1 also does not preclude the choice between copying or not
copying?

I do think both use cases could potentially be supported by a static context
property (in the Update Facility) that tells whether to copy or not. This
property could be modified, like any other, (i) at the implementation level,
(ii) at the module level and (iii) at the decision level.

I hope it helps.

Kind regards,
Ghislain

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

Received on Monday, 6 October 2014 09:07:02 UTC