[Bug 26958] On not precluding updates in XQuery 3.0

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

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

> (Having said that, I'm really not sure that to achieve what I think is
> needed, I would want to start from here. I'm afraid that the XML/JSON hybrid
> database we seem to be heading towards is a dreadful mess, at least as bad
> as the XML/relational or relational/object hybrid databases. Taking two
> reasonably clean but very different data models and crunching them together
> is not something, in my view, that in the past has ever produced a thing of
> beauty.)

I think the biggest need is to be able to support both XML stores and JSON
stores. In my world, I have a lot of simple object data represented as JSON,
often created by object persistence from JavaScript or Java objects, and I also
have XML and HTML documents. I want to be able to use this data together, but I
don't want to convert one into the other in order to do so.

Our model already says that XML nodes cannot contain maps or arrays, but maps
and arrays can contain XML, as in the second example from the original comment:

$x := <i>1 2 3</i>
$y := { "x" : $x }
$z := { "x" : $x }

That raises three questions for a database vendor.

1. Can I just refuse to store a hybrid structure like that?

Our languages let you create this structure, but you can imagine that some
vendors would not want to deal with it, because it adds complexity and may well
not be a mainstream case.

2. If I store this structure, do I need to maintain the identity of the element
so that updates to $x are propagated across $y and $z?

That would actually be a useful way to create a simple hierarchy of metadata to
describe XML documents, and you could imagine that someone would want to do
that. It also matches the run-time semantics we probably want in our languages,
where the identity of elements is exposed and can be tested. But I think it
would be fairly difficult with some existing data stores.  And it implies
semantics that would not survive serializing and parsing the data (but so do
our languages).

I don't think we want the in-memory semantics to differ from the semantics of
stored instances. Creating new copies of XML nodes when persisting the data
would make this a lot easier to implement in some environments, but it would
force us to change the semantics of our languages in ways that lose identity.

This is the most complicated case, and arguably not the highest value case. 
I'm inclined to find some way to say that it's OK to decide not to store such
an instance, but if you do, persisting it should not change the identity of the
XML nodes.

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

Received on Friday, 3 October 2014 14:02:55 UTC