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

[David Lee <dlee@calldei.com>]

=== Hans

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 association 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.

----------

Here is what I am contemplating.   Note that my recent ramblings on this list are a  "Mental Experiment" to see to me and hopefully get feedback, what our systems
Might look like if we changed a few things ... whether that means a new markup or a change to an existing one I am not suggesting either.  Just rather a step back inspired by 
Hans's "Info Space" and Mike's  "FtanML" and a few other thoughts that have been building in me.

Now to Hans's point.
I am suggesting that *perhaps* a better model/motto of a "Node"  is  "A node is content and possibly accessible by location".
First, even in XML as it stands nodes do not necessarily have a location so your current motto doesn't reflect current reality.
I.e.  in both XSLT and XQuery (and as was shown by Dimitre Novatchev, even in pure XPath) ... let alone any programming language that can make XML out of nothing ...
Nodes don't always have location.    So we already have broken this motto.
What I am suggesting is that's not bad, its vitial !     
I agree  that its vastly useful that you *can* get to a node via a "location" (either an explicit URL, query, or axis from another node), but I am willing to concede, if it provides value,
That we don't have to permanently assign a location to a node *NOR* do we have to impose the constraint that a node has only one location or identity.

What would this buy us ?
Nodes that are fetched, created, or extracted are of the same kind and have the same properties.  A more consistant node model.
You can use a URI to *get* or *create* a node but you cant then assume that node is associated with the URI after that (it may be dynamic, or may have multiple URI's).
So in a sense nodes can be retrieved/factored by "location" but then they become free of that association.
Nodes can be shared.  Imagine a representation of a typical BTree where each node is simply ( left, right , value )  or another kind of tree where a node is  ( value , list of children ) ...
If we don't enforce or expose or even implement node  identity in the  model, and don't have parents , then a nodes value can be shared in different trees. A node *itself* can be shared as well.
This has tremendous performance advantages both in-process and in a distributed system.  
In a distributed system it means we can construct single trees out of collections of child nodes of any size and location and their contents can be other nodes of any size and location (permanent or dynamic)
With no reguard at all to enforcing parentage or uniqueness.   This is in fact the model of resources in the web.   Does a web page have a parent ? Can it be shared ?  
So this means we can not only access nodes from anywhere (a file, constructed, the web, out of thin air) but that any tree can be created composing any of these nodes into another node, hierarchieally 
And lazily.
No distinction/difference between nodes that came from different kinds of constructors (documents, uris, other nodes, queried from DB's, dynamically created) - All the same and all equal model.


What we loose
No parent axis
No node identy (It is useless or misleading to ask if 2 nodes are the same, only if they are value equal)
No sibling access.  (without parent access you cant get siblings.  You can however, ask for siblings within the context of a  parent).
No document order.  (Order is only implied by walking children of a node,  a node itself since it can be shared may have many orderings)


I actually think this fits the concept of Hans' "Info Space" extremely well.  Better even ... 

Is it useful ? Are the benefits enough to accept the loses ?

-David