Thanks vastly to Hans-Juergen Rennau (hrennau@y...), 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