Alain,
I disagree that "a tree is a tree" in the manner that
you seem to mean it.
There are very significant differences between XML and
JSON, and nor
merely in their surface syntax. The most obvious such
difference is
that XML trees can be "annotated" (with attributes,
namespaces, et al),
while JSON trees cannot be. Another is that JSON trees
can incorporate
a node type completely foreign to XML trees -- arrays.
With tongue very slightly in cheek, I'll point out that
the X in
XPath/XQuery stands for "XML", and not for "Tree" or
"JSON" or anything
else. We could have created a JPath/JQuery, or maybe a
TPath or TQuery,
but our remit was to product a path language and a query
language for
XML. Having JSON support in that same language was not
exactly trivial
or uncontroversial, but we knew/know that JSON is a very
important data
model these days.
Hope this helps,
Jim
On 4/10/2016 11:36 PM, Alain Couthures wrote:
> Well, a tree is a tree, no matter if its notation
is this or that...
>
> It is a key point for XQuery/XPath to support axes.
In my own dev
> context, I would not say that I use ancestors or
siblings axes often
> but they really saved my days each time and with a
clean and concise
> syntax. As an implementor, I know that this has an
effective cost in
> memory and speed and that it might be tricky to
optimize.
>
> I understand that performance is important but
there are many
> situations where data to be processed is not that
big or where batch
> processing can be performed on underemployed
servers.
>
> Treating JSON more lightly than XML is a little bit
strange for me:
> why not, for the same "bad" reasons, decide to
manage no axes except
> descendants for XML too??
>
> All this might just be viewed as a runtime
optimization for
> implementations, don't you agree?
>
> Regards,
>
> Alain Couthures
>
> Le 11/04/2016 06:09, Dimitre Novatchev a écrit :
>>> This apparently trivial difference has some
interesting and profound
>>> consequences.
>>> Transformations of a tree in which many
branches of the tree remain
>>> unchanged become much more efficient,
>>> because (in an environment where in-situ
update is not allowed)
>>> copying a subtree has zero cost.
>> To give a specific and simple example
>>
>> 1. Sharing a subtree (between two trees) in a
binary search tree has
>> time complexity just O(log(N)) -- the time
needed to find the node in
>> a BST of N nodes. Compare to having to create a
complete copy of the
>> tree (which is necessary if a node can have no
more than one parent)
>> -- O(N). The same for creating a tree to which
just one node has been
>> changed (replaced) -- all tree nodes can be
shared with the exception
>> of the nodes on the path from the original root
to the node that must
>> be changed.
>>
>> 2. Sharing a subtree between M trees (or
creating a tree from the
>> original one in which M nodes have to be
changed) -- O(M(logN)).
>> Compare this to creating M complete copies of
the tree (which is
>> necessary if a node can have no more than one
parent) -- O(M*N).
>>
>> To put it simply, the difference in performance
is similar to that
>> between Quicksort and BubbleSort: O(N*log(N))
/ O(N^2)
>>
>> The same for space complexity.
>>
>>
>> Cheers,
>> Dimitre
>>
>>
>> On Sun, Apr 10, 2016 at 2:20 PM, Michael Kay
<
mike@saxonica.com>
wrote:
>>>> I was sorry to read that XQuery 3.1 is
not considering JSON data as
>>>> a tree: JSON is treated as a "complex"
atomic type, from my point
>>>> of view.
>>>>
>>> You can regard the output of parse-json()
as a tree (of maps,
>>> arrays, etc), but it is different from the
tree representation of
>>> XML. The main difference is that the maps,
arrays, etc produced by
>>> parse-json() have no parent.
>>>
>>> This corresponds closely to the way JSON
data is handled in other
>>> programming languages.
>>>
>>> This apparently trivial difference has some
interesting and profound
>>> consequences. Transformations of a tree in
which many branches of
>>> the tree remain unchanged become much more
efficient, because (in an
>>> environment where in-situ update is not
allowed) copying a subtree
>>> has zero cost. However, the lack of upwards
or sideways navigation
>>> means that during a recursive descent of
the tree, you need to pass
>>> a lot more context.
>>>
>>> For an exploration of the effect of these
differences on some
>>> transformation use cases, see my XML Prague
2016 paper.
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>>
>>>
>>>
_______________________________________________________________________
>>>
>>> XML-DEV is a publicly archived, unmoderated
list hosted by OASIS
>>> to support XML implementation and
development. To minimize
>>> spam in the archives, you must subscribe
before posting.
>>>
>>> [Un]Subscribe/change address:
http://www.oasis-open.org/mlmanage/
>>> Or unsubscribe:
xml-dev-unsubscribe@lists.xml.org
>>> subscribe:
xml-dev-subscribe@lists.xml.org
>>> List archive:
http://lists.xml.org/archives/xml-dev/
>>> List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
>
--
========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone:
+1.801.942.0144
Chair, ISO/IEC JTC1/SC32 and W3C XML Query WG Fax :
+1.801.942.3345
Oracle Corporation Oracle Email: jim dot melton
at oracle dot com
1930 Viscounti Drive Alternate email: jim dot
melton at acm dot org
Sandy, UT 84093-1063 USA Personal email: SheltieJim at
xmission dot com
========================================================================
= Facts are facts. But any opinions expressed are the
opinions =
= only of myself and may or may not reflect the
opinions of anybody =
= else with whom I may or may not have discussed the
issues at hand. =
========================================================================
