XInclude WD 22-March-2000 comments

Greetings XIncluders.

Some suggestions:

1) Although "inclusion is accomplished by merging a number
of XML Infosets into a single composite Infoset", this mechanism
is a very natural fit for inclusion of non-XML documents.  Why
not allow for (full) document inclusion of non-XML documents,
via parse="none", or some such mechanism.

2) I'm uncomfortable with allowing XIncluders to control
whether an included location set will create CDATA or
text nodes. This distinction really is a prerogative of an XML
*writer*, not an XML *reader*.  As such, I think that the
parse attribute values should be restricted to "xml" and "text".
This neatly avoids the problem you mention of nested CDATA
sections--as always, it's up to the serializing code to properly
escape the character data when necessary.

3) The relationship of XInclude to XSLT really ought to be
mentioned.  Does it matter, given an infoset which will be
augmented by XInclude *and* transformed by XSLT, whether
one of these is first?  Should one always precede the other?

4) Someone on XML-DEV mentioned character content for
the <xinclude:include/> element, to be used for an HTTP POST
operation (instead of the GET operation implied by the href attribute
value).  Another possibility is XSLT scriptlet character content,
to be applied to the nodeset before merging.

5) In section 3.2, you allow that a merged infoset might contain
mixed encodings.  This breaks an assumption of XML:

    One document, one encoding!

Since Infoset does not expose encoding as a document property,
we may be stuck, but that's not the way it *should* be.

Steve Rowe
MNIS-TextWise Labs

Received on Saturday, 8 April 2000 02:39:24 UTC