[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: An XML API using Java streams

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: Michael Kay <mike@saxonica.com>
  • Date: Sat, 24 Jun 2017 04:13:43 +0000 (UTC)

Re:  An XML API using Java streams
Let me elaborate the thought that new approaches to navigation might profit from a thorough appreciation of the achievements of XPath.

One of the profoundest, yet most elusive, aspects of powerful ideas is the basic *units* which they presuppose or create. Object orientation is a wonderful example, as is Functional Programming, and a negative example is the relational database system (problems caused by the lack of a unit matching domain entities, which cannot be captured without ephemeral joins).

Over abstraction leads to base entitites which are too shapeless - while in principle you might reassemble them into meaningful constructs, this reassembly is overly complex. Under abstraction leads into a clutter.

Concerning navigation, the DOM API is under abstraction. Over abstraction would be the conclusion that, given that navigation is just a mapping of locations to locations, navigation is already implemented by the flatmap() function. Better, but still over abstraction, would be the postulation of two primitives, mapping and filtering (directly supported by the Streams API functions flatmap() and filter().)

The achievement of XPath may be described as an ingenious definition of *units* giving structure to the overall operation of navigation. The "navigation is a sequence of steps" view is extremely important, but also trivial. Non-trivial, however, the model of a step, a compelling shape composed of "mapper" and "filter" subunits:

step ::= mapper filter*
mapper ::= standardMapper | customMapper
customMapper ::= expression
filter ::= expression
standardMapper ::= axisMapper axisFilter
axisMapper ::= child | descendant | ancestor | ...
axisFilter ::= nameTest | kindTest

Our two primitives - mappers and filters - are arranged into three basic units: axisMapper, axisFilter, expression. Now we can decompose navigation into two levels: level#1 steps, level#2 the step components (axis, node test and predicates). The reduction of complexity is so successful, as the technical model matches our mental model of navigation closely.

Concerning the Streams API - it is a highly encouraging fact that the key abstractions of navigation - mapping, filtering, chaining - are key abstractions of the API itself (flatmap(), filter(), stream-in-stream-out model). But here come the crossroads: will the emerging navigation API follow XPath in the recognition of a unit "step" which is *ABOVE* the primitives mapper and filter? Looking again at your explorative example:

N.walk(Axis.child("city")).map(Axis.attValue("name"))

a step model is not yet quite obvious. Interesting, here, also your concern with syntax, which reveals to the eye step units otherwise obfuscated by syntactical clutter.





Michael Kay <mike@saxonica.com> 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@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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.