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 ? 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 |