Thank you, Alain, most
interesting!
Attempting to summarize
your approach, I would say:
* extension of the XPath node model (by new node
kinds)
* extension of the XPath navigation model (by new node tests and
new operators);
* extension of the parsing+serialization model, connecting multiple formats to a unified data model
=> extension of XPath navigation beyond XML
I believe your model and exml point in a
promising direction, and I am curious about similar efforts elsewhere, as
well as other directions to go.
And a very important aspect of your approach is that it does not advocate any particular data format in preference of another, but achieves a unification beneath the syntax level, at the model level.
(About one interesting aspect of your model I am not sure - do the navigation axes drill down into maps and arrays - so that, for example, foo/descendant::bar might return map entries named "bar" - or do they deliver map and array nodes as a whole, so that drilling down into them is handled by the lookup operator "?"?)
With kind regards,
Hans-Jürgen
Alain Couthures <alain.couthures@agencexml.com> schrieb am 22:01 Sonntag, 10.April 2016:
Hello,
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.
I have been implementing parsers for non-XML data, such CSV or
JSON for example, which construct DOM trees with nodes with
specific node types for arrays and maps. Then, using an XPath
syntax for navigation requires just few extensions!
This has been presented at XML Amsterdam last November:
http://www.agencexml.com/amsterdam2015/Processing_non-XML_sources_as_XML.pdf
Best regards,
Alain
Le 10/04/2016 21:42, Hans-Juergen Rennau a écrit :
Thank you, Dana
and Liam.
Does JSONiq
support navigation axes apart from the child axis?
Concerning
XQuery 3.1, my reading of the spec is that support for JSON
navigation (the lookup operator) is restricted to the child
axis.
My feeling is
that support for other navigation axes besides the child axis
is an essential feature of XPath.
With kind
regards,
Hans-Jürgen
JSONiq had relatively sophisticated path
expressions sublanguage, but designed specially for
JSON.
Not all the “tree”
structures are alike.
As for path expressions,
during the 1990ies there was SO much work on
that…..interested
parties should go back in
time and read the literature.
HTH,
Dana
Dear
colleagues,
the navigation
model of XPath - navigation viewed
as a sequence of steps, a step
viewed as a combination of
navigation axis, node test and
optional predicates - enables the
expression of item selection in a
clear, concise and very readable
way. But I do not think that the
basic principles of the navigation
model depend on XML trees, rather,
that variations of the XPath model
could be designed for other kinds
of tree-structured information.
Yet the only
attempt to do so which I am aware
of is JSONPath.
I would be
interested in learning about other
approaches to apply XPath-like
navigation to non-XML structures -
can you help me discover them?
And do you have
thoughts about why one should not
- or should - attempt such
approaches?
With kind
regards,
Hans-Juergen
