Thanks vastly to Hans-Juergen Rennau (hrennau@yahoo.de), I've been re-animating my proposal for an XDM Serialization specification (http://xml.calldei.com/XDMSerialize) which can accommodate much more round-trip data preservation then the
current XDM Serialization specification (http://www.w3.org/TR/xslt-xquery-serialization/ )
Please be patient with the draft if you care to read it, it’s a work-in-progress not really ready for public consumption (but by putting it on a wiki allows easier collaboration then emails).
Maybe "Really Soon Now" but not now yet …
One thing I am stuck on currently is serializing XDM document-node() which contain text children.
I can certainly imagine a format, but I'm more curious as to the rationale.
Q) Why does XDM allow text() children of document nodes, and in fact allow multiple element children of document nodes (If I read it right …)
For example in XQuery this is allowed
document { text { "text" } , <elem1/> , text { "text2" } , <elem2/> }
I'm wondering what is the use-case that led to this ?
My best "clue" is a recent question/response on xslt-list which made it clear to me that <xsl:variable> produced a document node, but it could contain parentless text nodes
I certainly understand the desire for XDM to allow parentless text, element, and attribute nodes …
but I don’t understand the use case for document nodes containing text and multiple element nodes …
Am I correct in presuming this is to support XSLT 1.0 (and perhaps by inference XQuery 1.0 ) which allowed this ?
Is it a chicken&egg problem ?
What is the rationale for allowing document nodes to contain children which are not parseable from Text XML ?
Is this a critical feature to maintain in a round-trip XDM serialization specification ? ( Yes I realize I'm asking for an opinion not an objective fact).
Thanks for any advice, opinions, or historical anecdotes.
-David
----------------------------------------
David A. Lee
dlee@c...
http://www.xmlsh.org
Cart
