Re: [xml-dev] YPath, ZPath?

[Dan Sullivan <dsullivan@danal.com>]

Actually there is an XML syntax for XQuery, https://www.w3.org/TR/xqueryx-30/


Dan






On 4/11/16, 2:20 PM, "Alain Couthures" <alain.couthures@agencexml.com> wrote:

>Jim,
>
>I did not say in my previous message that XML node types are enough for 
>a JSON tree. That's why I added new node types, one for array for example.
>
>Today, this X is seen as outdated. XPath and XQuery don't have an XML 
>syntax, by the way. There are some lacks in XML such as typed values not 
>supported (just typed elements or attributes) which are present in 
>XPath/XQuery...
>
>My intent is not to impose ideas because there are always people to say 
>it's rubbish, and Internet is big enough for that.
>
>I am my own implementor for my own purposes and it is opensource, just 
>in case other people might be interested. I don't have a big company 
>power to say that it is better than anything else. I am used to think 
>differently, that's all...
>
>Le 11/04/2016 19:25, Jim Melton a écrit :
>> 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
>>>>
>>>>
>>>
>>>
>>> _______________________________________________________________________
>>>
>>> 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