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

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
when what you really want to say is

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

[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