- From: <bugzilla@jessica.w3.org>
- Date: Mon, 06 Oct 2014 13:47:52 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26958 --- Comment #7 from Jonathan Robie <jonathan.robie@gmail.com> --- (In reply to Ghislain Fourny from comment #5) > 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. Or perhaps we could leave this choice to the persistence layer, which is outside of what our specs actually define, but which we can talk about in notes and guidelines. I don't think we need to support shared sub-arrays or shared sub-maps. As long as that is not needed, this might work: 1. Maps and arrays support in-situ update (which can be represented in PULs). This implies identity. 2. Construction uses copy semantics for maps and arrays, but not for nodes. 3. A persistence layer can choose whether to create copies of nodes found in maps and arrays instead of preserving their identity, or refuse to store a map or array that contains nodes. Ideally, I would like this to be documented, could we make it implementation-defined? I'm not sure we can, I'm not sure that this is actually in the scope of what our languages define. 4. Updates work the same way on any XDM. Only #3 distinguishes implementations. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 6 October 2014 13:47:56 UTC