Comments on XInclude.

XInclude provides some useful concepts, but does not seem to offer 
enough to become a standard.

I like XInclude better than external entities.  But I cannot accept it 
as useful enough in its current form.  DOM, for example, will be forced 
to continue to support entities while being pressed to support new 
extensions just to contend with this new standard that doesn't buy us 
enough to make things simpler.  This will be a losing proposition for 
DOM and every specification which builds upon DOM, IMO.  Complexity 
grows for no good reason.

Users already have entities, which XInclude does not allow us to drop 
because it is not powerful enough to solve the use cases for entities.

>
>       1.2. Relationship to XML External Entities
>
> There are a number of differences between XInclude and XML external 
> entities [XML] <http://www.w3.org/TR/2001/WD-xinclude-20010516/#XML> 
> which make them complementary technologies.
>
The differences do not overpower the great redundancy.

> Processing of external entities (as with the rest of DTDs) occurs at 
> parse time. XInclude operates on information sets and thus is 
> orthogonal to parsing.
>
In the case of entities, creation of the infoset is performed by the 
parser, which then may or may not expand the external entities.  Since 
the infoset may contain unexpanded entities, these entities could easily 
be expanded at a later date as part of an infoset operation.

In the case of XInclude, some parsers are quite likely to perform the 
XInclude transform as part of their operation, or leave it to someone 
else as a delayed infoset transform.

I like the concept of the infoset transform.  But in every day use it 
does not spell any great difference between the two.

> Declaration of external entities requires a DTD or internal subset. 
> This places a set of dependencies on inclusion, for instance, the 
> syntax for the DOCTYPE declaration requires that the document element 
> be named - orthogonal to inclusion in many cases. Validating parsers 
> must have a complete content model defined. XInclude is orthogonal to 
> validation and the name of the document element.
>
If between XInclude and XML Schema, we could generally get rid of the 
internal and external subsets, this would be a powerful argument.  But 
neither one provides for entities.  The most common specifications such 
as XHTML rely extensively on entities, so we are stuck with internal and 
external subsets.

The name of the doctype is in no way related to the entity declarations. 
 The doctype has to match the root element.  That isn't a big problem. 
 Entities are already orthogonal to validation, even though they appear 
in an internal or external subset.  Non-validating parsers still are 
required to parse the internal subset for entities and default 
attributes.  Every non-validating parser I ever wrote honored external 
entity references in the internal subset.  So, I see no advantage here, 
unless I can use XInclude to solve entities as well.  If we can 
eliminate internal and external subsets using XInclude and XMLSchema, 
your argument works.  But we cannot.

> External entities provide a level of indirection - the external entity 
> must be declared and named, and separately invoked. XInclude uses 
> direct references. Applications which generate XML output 
> incrementally can benefit from not having to pre-declare inclusions.
>
Nice, but not compelling or really orthogonal.

> The syntax for an internal subset is cumbersome to many authors of 
> simple well-formed XML documents. XInclude syntax is based on familiar 
> XML constructs.
>
Nice, but not compelling or really orthogonal.

>
>       1.3. Relationship to DTDs
>
> XInclude defines no relationship to DTD validation. XInclude describes 
> an infoset-to-infoset transformation and not a change in XML 1.0 
> parsing behavior. XInclude does not define a mechanism for DTD 
> validation of the resulting infoset.
>
XInclude is generally incompatible with DTD validation, because the DTD 
validation is not defined as an infoset transformation.  While it can be 
made to work on an infoset, there is nothing in the document which would 
suggest to most validating parsers to defer validation until all the 
pieces are put together again by XInclude.

This would be great if we could eliminate the DTD, but we cannot because 
we have entities which are used for a wide variety of purposes within a 
document.

XHTML, for example, still relies on DTDs, and I expect will continue to 
rely on them until a specification comes along that can provide some 
alternative method of character entity support (I made such a straw man 
proposal informally that did not seem to harm XML 1.0).  But along comes 
XInclude 1.0 and the expectation will be that new standards should 
support it, even though it really is not helpful to XHTML in its current 
form.

>
>       1.5. Relationship to Grammar-Specific Inclusions
>
> Special-purpose inclusion mechanisms have been introduced into 
> specific XML grammars. XInclude provides a generic mechanism for 
> recognizing and processing inclusions, and as such can offer a simpler 
> overall authoring experience, greater performance, and less code 
> redundancy.
>
If these grammars did not use external entities, why would we expect 
them to suddenly decide to use XInclude?  People who like to invent 
private mechanisms will still invent private mechanisms.  I have created 
a number of XML grammars that used external entities to good benefit.

XInclude seems to me to be part of an effort to stamp out entities.  For 
example, SOAP or XML protocol, while claiming to be XML, apparently 
forbids XML with entity references, such as XHTML.  I like the direction 
if someone is willing to make a good alternative proposal.  XInclude is 
good, but not an alternative for many situations, so those who continue 
to need the features omitted are left stranded when we get standards 
like SOAP which ignore the need and use cases for entities -- even 
though entities are a core part of XML 1.0 and SOAP claims to be an XML 
protocol for communicating XML from point a to point b -- and claim that 
xinclude is all that is needed, just because that is all that they 
happen to use entities for.

I therefore dislike XInclude in its current form.  I think it is worse 
than doing nothing.  I made the comment before, but my comments did not 
cause a change in direction, so I am restating it more strongly.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 5 June 2001 18:33:07 UTC