OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XPath and a continuous, uniform information space - Recap


wait a minute. Let us assume for a moment that secondary structures provided by nodes being or containing maps - thus having named pointers to other nodes - bring important benefits, namely the emergence of additional trees and graphs within the primary node forest.

Then we can overcome the basic problems you summarized by slightly constraining our map concept. (At least I think so.) Remembering our chief goal - using maps-in-a-node in order to allow nodes to contain named pointers to other nodes - we may be ready to switch our language and do not speak of maps containing nodes - but maps containing node references. If we introduce a new atomic type with the semantics of a node reference (e.g. an XPointer-like syntax?), then node references are serializable, maps-in-a-node are serializable, round tripping is saved.

Conclusion: maps-in-a-node are workable, provided we succeed in defining serializable node references in a satisfactory way. Is that a serious problem? Sometimes less is more: by accepting within nodes a "lesser" kind of maps, we might achieve a standards-based way how to interlink nodes in a novel way and construct additional trees and graphs, residing within the primary node forest.

Coming back to the start: I *assumed* that those additional structures created by maps-in-a-node are important. The assumption might be wrong - I do not know.


PS: To avoid a misunderstanding: the idea is not to equate "map" with a node, but to define map as an independent item type (as XSLT does) and reuse it when extending the node model - therefore we would not "burden them [maps] with identity and parentage" - maps-in-a-node do not create any additional node identity.

Von: Michael Kay <mike@saxonica.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>
CC: David Lee <dlee@calldei.com>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 19:50 Samstag, 17.August 2013
Betreff: Re: [xml-dev] XPath and a continuous, uniform information space - Recap

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS