Dan,
You're right but this is not really a human friendly syntax...
I actually use an internal format in my XQuery engine which has the very
same structure as XQueryX but with Javascript nested arrays to be
interpreted for evaluation. I am quite happy with this structure, even
if some XQueryX elements are useless... So, compiled expressions can be
serialized back as XQueryX.
If you look at my paper at XML Amsterdam last November, you will read
that I defined XSLTX as XSLT with XPath expressions converted into XQueryX!
Alain
Le 11/04/2016 20:26, Dan Sullivan a écrit :
> 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" <> 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 <> 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:
>>>>>> subscribe:
>>>>>> 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:
>>>> subscribe:
>>>> 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:
>> subscribe:
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
