XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] An XML API using Java streams


On 23 Jun 2017, at 11:41, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

As the expressiveness of XPath is excellent (and I think - not to be surpassed),

Well there are certainly some improvements that one could contemplate:

* Separating positional filters from boolean filters so they are syntactically distinct

* A clearer separation between the "/" and "!" operators

* A more orthogonal set of axes, e.g. allowing an "or-self" modifier with any base axis

* Representing attributes using maps rather than as nodes

But yes, the basic model is pretty sound. Axes are functions from nodes to sequences of nodes, the "!" operator is a flatMap() operator, "/" is flatMap followed by deduplication and sorting-into-document-order, boolean predicates a pure filter() operation.

A lot of the messier things come from lack of orthogonality and unnecessary complexity in the data model (notoriously namespaces) and XPath does a pretty good job at smoothing over some terrible cracks.

Michael Kay
Saxonica


any fresh attempt at a navigation model might profit from a comparison of its key principles with the key principles behind XPath. I would summarize the latter as follows:

(1) Navigation is a sequence of steps.
(2) A step is a mapping of current locations to next loations.
(3) A step is either a standard step or a custom step.
(4) A standard step has a direction (axis) and a simple standardized filter (node name or kind).
(5) A step can be extended by custom filters.
(6) The addition of step filters does not increase the complexity of the navigation.
(7) Step semantics are self-contained and any step can be applied to any input


Michael Kay <mike@saxonica.com> schrieb am 16:00 Donnerstag, 22.Juni 2017:



(2) A great challenge - and perhaps a hopeless one - would be to create an expressiveness which could at least be a far cry of what XPath offers. It is strange to say
     N.walk(Axis.child("city")).flatMap(Axis.attribute("name").map(Node::stringValue)
when what you really want to say is
     city/@name


Excellent point. However, dropping into another language does have all sorts of disadvantages: apart from the learning issues, there's the lack of compile-time syntax checking and type checking, the cost of dynamic compilation/interpretation, etc.

One thing to look at, perhaps, is how it translates into Scala, where you can define your own operators:

A.flatMap(B)   -->   A/B

A.attribute(B)  -->   A @ B

etc; and then we start to have something very XPath-like, but with a syntax that's compiled and validated by the host language.

Michael Kay
Saxonica 






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS