- From: Hans-Juergen Rennau <hrennau@y...>
- To: Michael Kay <mike@s...>
- Date: Sat, 24 Jun 2017 02:41:07 +0000 (UTC)
Interesting points. (Although I disagree, concerning attributes.) By the way, you misunderstood me - I did not mean to say that XPath could not be improved, but that non-XPath approaches to navigation will probably not excel XPath in terms of expressiveness and readibility.
Michael Kay <mike@s...> schrieb am 17:25 Freitag, 23.Juni 2017:
On 23 Jun 2017, at 11:41, Hans-Juergen Rennau < hrennau@y...> 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@s...> 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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
Cart
