Re: [xml-dev] YPath, ZPath?

[Dave Pawson <dave.pawson@gmail.com>]

A real XML discussion! What a pleasure.
Purely self reasons, and now that W3C has stepped up to the mark
with CSV, I wonder if ?path could be developed for either a more
general model or more targeted at json, csv... (any more candidates?)

If the XSLT, XQUERY constraints were removed (MK comments "I wouldn't
start from here") what might such a model look like and would it have
a significant use case?

Just noodling.


regards





On 12 April 2016 at 17:57, Jim Melton <jim.melton@oracle.com> wrote:
> Han-Juergen,
>
> No, my argument is not what you suggested in your point (c).
>
> My argument is that XPath (including XDM, XQuery, et al) was created with a
> design center of XML.  Yes, it has been extended to support JSON as well,
> but I doubt sincerely that a hypothetical JPath/JDM/JQuery (that is, with a
> JSON design center from the beginning) would look very much like
> XPath/XDM/XQuery.
>
> There were very good reasons for the design decisions that we made for
> XPath/etc. originally, and there were very good reasons for the different
> design decisions made for the application of XPath/etc. to JSON data.  And
> that includes the reasons behind the decision that JSON "nodes" do not have
> parents, siblings, etc.
>
> Hope this helps,
>    Jim
>
> On 4/12/2016 1:56 AM, Hans-Juergen Rennau wrote:
>
> Jim,
>
> you wrote:
> "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."
>
> I do not understand the argument. Please consider:
> (a) XPath was designed for processing XML, but extended to support
> processing of JSON [fact]
> (b) The XPath data model (XDM) was designed for processing XML, but extended
> to support processing of JSON [fact]
> (c) The node sub model of XDM was designed for processing XML, but must not
> be extended because it was designed for processing XML [your argument?]
>
> With kind regards,
> Hans-Jürgen
>
>
> Jim Melton <jim.melton@oracle.com> schrieb am 19:26 Montag, 11.April 2016:
>
>
> 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
>
>>
>
> --
> ========================================================================
> 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.  =
>
> ========================================================================
>
>
>
>
> --
> ========================================================================
> 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.  =
> ========================================================================



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk