RE: Comments on XInclude.

Thanks for your comments.  They have sparked an interesting discussion
in the Core WG.  Some responses below.  I am cross-posting the Core WG
so the whole WG is aware of your reply.

> -----Original Message-----
> From: Ray Whitmer [mailto:rayw@netscape.com] 
> Sent: Tuesday, June 05, 2001 3:37 PM
> To: www-xml-xinclude-comments@w3.org
> Subject: 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.

It appears however that you favor an even greater level of redundancy.
Is this correct?

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

Because XInclude does not solve all the problems for every vocabulary
doesn't mean it isn't useful for many vocabularies.  The Core WG feels
that even a minimal 1.0 inclusion facility that isn't 100% redundant
with entities would benefit a substantial user community.  Since
XInclude is the wrong place to deprecate entities, making entities and
XInclude live together seems the best transitional strategy.

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

Indeed, Xinclude by itself is not sufficient to replace all use of
internal and external subsets.  It does not provide a more useable
syntax for charater references, or arguably internal entities.  It
simply does not provide for entities in attribute values at all.

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

It is hard to find an objective criteria to judge whether XInclude is
compelling enough to puruse.  Many of us feel it is, and have received
feedback from early adopters that enjoy the technology.  In the end we
have to weigh your views, make our best guess as a WG, and let the
membership and the public (voting with their wallets) decide.  So far
the Core WG has not been pursuaded by your arguments to drop XInclude
development.

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

XHTML relying on DTDs and XHTML authors relying on DTDs are not
necessarily the same thing.  I feel the majority of XHTML users will not
be messing around with internal subsets and DTD syntax, just using the
named character references.  For these users, XInclude seems like a big
useability win.

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

It is not the "grammar" that disallows entities (indeed this violates
XML), it is the users that are finding entities insufficient or
inaccessible to the modularization tasks at hand.

> XInclude seems to me to be part of an effort to stamp out 
> entities.

Clearly the useability problems with entities are a motivation for
XInclude, but it is not a goal of XInclude to "stamp out entities".
This is outside the scope.  It is to provide users an alternative
modularization functionality which overcomes some of the limitations of
entities (like no XPointer support) in a convenient, recognizable syntax
(XML).

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

Thank you, I'm glad you aren't pulling any punches.  These comments are
certainly welcome in evaluating our work at this point.  But we feel
that how good a job XInclude does in stamping out entities is not the
primary criteria by which it should be judged, but rather how useful is
it to authors in addressing modular document authoring scenarios.  We
have some early indications that it will be welcomed by that community.

> Ray Whitmer
> rayw@netscape.com
> 
> 
>

Received on Thursday, 28 June 2001 10:13:35 UTC