Re: [xml-dev] YPath, ZPath?

Alain, there is a German phrase "ein wahres Wort gelassen aussprechen" (to utter a true word calmly).

That is what you did. How would the XML community react to the announcement that in XPath/XQuery/XSLT 4.0 all navigation axes except for the child and the attribute axis will be removed, due to performance issues?

With kind regards,

Hans-Jürgen

PS: An anecdote related to EXML. Once, attending a conference, I chatted with a man who is a wonderful thinker, speaker and engineer, whom I deeply admire and will never cease to regard as a teacher. He lightly remarked upon that "in JSON there are no nodes". I stared at him with open mouth and widened eyes and interrupted him (one should not do that) - "How can you POSSIBLY say that? There are no nodes in XML either, it all depends on how we model the formats." Unfortunately, at this moment the elevator door opened and Michael stepped in (or out, I don't remember), and said "Goodnight!".

Alain Couthures <alain.couthures@agencexml.com> schrieb am 7:36 Montag, 11.April 2016:

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
>
>

_______________________________________________________________________

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