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

Re: XPath and a continuous, uniform information space

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: David Lee <dlee@calldei.com>, John Cowan <johnwcowan@g...>, Uche Ogbuji <uche@o...>, "costello@m..." <costello@m...>
  • Date: Sat, 17 Aug 2013 10:09:07 +0100 (BST)

Re:  XPath and a continuous
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@o...>
CC: Gareth Oakes <goakes@g...>; Peter Hunsberger <peter.hunsberger@g...>; "xml-dev@l..." <xml-dev@l...>
Gesendet: 7:10 Samstag, 17.August 2013
Betreff: RE: 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
 
 
 




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