Off the cuff comments on XInclude

A few comments on http://www.w3.org/XML/Group/2000/03/WD-xinclude-20000314

I feel the fact that XInclude is declared to be "orthogonal" to parsing and
validation is cheating.  Validation, I assume, can in practice be carried
out on the
document as a string of bytes or on the infoset. The validity of documents
before and after
XInclusion are both interesting, but after is more fundamental.  There isn't
much point in validating something when you have no idea what is going to
x-included.
One needs to be careful that this specification redefined validity (schema
or DTD) to apply to the FINAL infoset.  This is the only thing which makes
sense.


This suggests to me that issuing an XML 1.1 which puts XML, NS and Xinclude
into a single framework would probably be useful to the user community.
After all, if you are using XInclude, processing of it is unlikely to be
optional.  We are raising the bar for XML processors - rightfully so IMHO.

2. Requirements

"The result of an inclusion shall accommodate XML 1.0 and XML Namespaces".
I am not sure what "accommodate" means. Provide a living space for?

3. Processing Model.

"the base URI be surfaced" ?  Would I understand that if I read the DOM
carefully?

3.2 The parse attribute is quite fundamental.  When an attribute totally
changes the effect of the element, I would prefer making 3
different elements, xinclude:text, xinclude:xml and xinclude:cdata. (or
xml:include-text, xml:include, and xml:include-cdata)


The spec says, "Any xinclude:include elements in this infoset are
recursively
processed" but this applies of course only to XML parsing.


Issue 03-nesting-optimization uses the term "knitted".  which is not one I
use every day for documents.  What is "knitting a document"?  I therefore
don't
understand the issue.

3.1 Document nodes

change: "The XML declaration in the included document is ignored. The
document type declaration information item in the included document is
ignored." to:
"Any XML declaration in the included document is ignored. Any document type
declaration information item in the included document is ignored." as these
are optional and need not be present in the first place.


--

The fact that the top-level document element does not appear is IMHO a
problem, in that you may well want to include it!  In future namespaces
there my be many information-containing options for the document  node.

Also, this is unclean.  It is a an unnecessary special case.  The algorithm
is to include a referenced element unless it is a document element, in which
case include the content.  maybe it would be cleaner to split xml:include
into xml:include (referenced language element) and xml:include-contents
(contents of referenced element).

--

3.3.2 "If the document element in the source infoset is an xinclude:include,
it is an error to attempt to replace it with more than a single element."
That is unfair on the include processor: I would say it is an error on the
part of the author of the
source.  (Actually IMHO this points to an arbitrary constraint in XML that a
document should have only one document node but let's not go into that!)


--

Issue 32:  No, I would suggest that attribute-level inclusion not be
provided.   This spec is simple as it is.  It would be complicated if it
allowed attribute inclusion.

--

Issue 31:  This points toward an XML 1.5  = XML + NS + XInclude level spec.


--

Validation - "processor will validate"    (This process-oriented
specification is very traditional in SGML but it makes for bad specs IMHO.
Don't define what processors do, define what things *are* and what they
*mean*.
Why should an XInclude processor validate its output? It may ant to process
the document without validating it.

What is a   dtd-valid XML document? What is a schema-valid document? Answer:
the result of validation after all Xinclusion.  This specification redefines
the meaning of a valid document for any document containing  an element
defined here.


Tim BL
wearing no hat

Received on Tuesday, 21 March 2000 13:36:55 UTC