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

Re: XPath and a continuous, uniform information space - Recap

  • From: Michael Kay <mike@saxonica.com>
  • To: Hans-Juergen Rennau <hrennau@yahoo.de>
  • Date: Sat, 17 Aug 2013 18:50:21 +0100

Re:  XPath and a continuous

On 17 Aug 2013, at 17:53, Hans-Juergen Rennau wrote:

Is there no way how we can lift the map model of XDM *into* the node model? 

Only if you break the constraint that every element node in XDM can be losslessly serialized as an element in XML. (Well, "losslessly" except for the type annotation...).

XDM has some fundamental non-orthogonalities built into it, all derived from non-orthogonalities in XML. For example:

* attributes cannot hold any value, they can only hold strings

* elements cannot contain any value, they can only contain sequences of certain kinds of nodes

For maps we wanted the value part of a (key-value) pair to be ANY value, and to achieve that using element nodes would require an extension of XDM element nodes to the point where they bore little relationship to elements in XML. You could make map (and map-entry) into new kinds of node, and we considered that option, but then you would burden them with identity and parentage which we didn't want. Part of the reason for that is that with immutable data, we wanted creation of a new map by adding an entry to an existing map to be a cheap operation, and that's hard to achieve if every existing "node" in the old map has to acquire a new identity. Currently with XSLT it's very expensive to construct a document that differs in a very small way from an existing document: the cost is typically proportional to the size of the existing document; that's because it's required that every node in the new document has a distinct identity from the corresponding node in the old document, which is hard to achieve (though I dare say it might be possible if one tried harder) without making a physical copy.

It's worth recalling here the problems with using the node model for namespace nodes. Many implementors have complained about the cost of implementation of the namespace node model (which is why it wasn't carried over into XQuery). You either implement it naively, which is very inefficient because there are such large numbers of nodes, or you devise some kind of scheme for virtual nodes that are instantiated on demand (as Saxon does) which is very complex to implement. The complexities are only there because namespace nodes have identity and parentage, yet infinitessimally few applications actually depend on the identity and parentage of namespace nodes. Implementing them as a (prefix->URI) map would have been far simpler.

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.