Re: [xml-dev] XPath and a continuous, uniform information space

David,

I have difficulties to understand this direction of the discussion, let me explain why.

A motto of mine is: "A node is both, content and location" - and I believe that this is a miraculous formula, we have hardly scratched the surface of its potential. The association of information with location is a principle as fundamental as the assocation of data and methods (object orientation).

I do not think you want to get rid of "location". But what is this, location? Some models: a register; a memory address; a variable name; a combination of database/table/column name; a RDF triple subject URI; a NOSQL object and a data path; a node.

The XDM provides us with an elaborate location model: an entity called "node" endowed with properties, among which several related to the concept of a location: [document-uri], [children], [parent], [attributes]. What we get out of it is, for example, XQuery and XSLT. What we can squeeze out of it is expressions like $xsds//xs:enumeration[@value = 'Vacant']/ancestor::xs:schema/@targetNamespace.

I do believe that we should think about extending (and possibly at the same time pruning) the model, think about a next generation - especially bearing in mind that the model might cover more than XML, that the model might become a unified data model supporting many data formats. This is my notion of progress and evolution. I believe that the alternative - to do away with nodes - can point to interesting solutions for specific problems (e.g. when dealing with a huge map of maps and nothing else), but that it is inappropriate for more than that - inappropriate as a foundation to support anything comparable to the current info space (= sum total of XML resources + XPath/XQuery/XSLT).

If feelings emerge that we perhaps should consider radical changes, offering significant advantages, then I would like to ask five questions:

(a) Is the "content + location" formula (= the node concept) still accepted?
(b) If yes - what would be a new and alternative node concept - what would be the node properties?
(c) If no - which entities replace the node, what are their properties?
(d) Yes or no - what would be the principle advantages concerning navigation and integration?
(e) Yes or no - could you sketch a practical usecase and the user experience of its solution?

Cheers,
Hans

Von: David Lee <dlee@calldei.com>
An: John Cowan <johnwcowan@gmail.com>; Uche Ogbuji <uche@ogbuji.net>
CC: Gareth Oakes <goakes@gpslsolutions.com>; Peter Hunsberger <peter.hunsberger@gmail.com>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 7:10 Samstag, 17.August 2013
Betreff: RE: [xml-dev] XPath and a continuous, uniform information space

```````````` John Cowan

The Ftan paper says specifically in the FtanML data model section that a FtanML element is just its name and its attributes (the content value is an attribute named by the empty string). It's a pure, if compound, value, like a mathematical ordered pair or a complex number, and has no notion of being embedded in a specific context, hence no parent. This means that it's a no-op to make a copy of a Ftan element, just as it's a no-op to make a copy of 32+45i.

----------

Yes this is the data model to which I was referring. Of all the FtanML this was the most thought provoking to me.

The syntax itself I am on the fence about, but the concept of unchaining the node model from the document has some very compelling features.

By discarding the concept of node identify you then can discard concept of document order, document identity. Along the way you have to give up

ancestry (and I think the sibling axis). But if you do the advantages are compelling.

No longer is the node tied to a resource. While its true XML has anonymous nodes (say explicit constructors in XQuery) ... if ALL the nodes are like this,

then to my thinking it relieves many barriers to a distributed data model. Data can come from anywhere as first-class citizenry.

You dont have to drag along with it any concept of its roots or even if it *had* roots ... The performance aspects are interseting, not only in

processors for internal data but in the sense of not having to restrict nodes to belonging to documents they could be parts of graphs,

shared data, independent data, free data in a nearly literal metaphor.

I havent fully brought this metaphor to ground in my mind yet but there seems something very enabling about it. You dont have to think of Data in Documents or any kind of container anymore ... and the processors dont have to struggle to maintain that model representation.

-David