RE: Comments on XInclude

The WG looked at the DTD and couldn't find ways to make it more
consistent with the schema.  The WG was also reluctant to remove it
altogether, as it provides a concise and familiar syntax for describing
the content model.

If you don't agree, please let us know by June 30 so we can revisit the
issue.  Thanks again for your comment.

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Saturday, April 06, 2002 8:30 AM
> To: Roger L. Costello; www-xml-xinclude-comments@w3.org
> Subject: RE: Comments on XInclude
> 
> Thank you for your comments, and your patience in awaiting my reply.
> 
> > -----Original Message-----
> > From: Roger L. Costello [mailto:costello@mitre.org]
> > Sent: Saturday, March 30, 2002 8:31 AM
> > To: www-xml-xinclude-comments@w3.org
> > Cc: costello@mitre.org
> > Subject: Comments on XInclude
> >
> > 1. The DTD shown in the document is inconsistent with the schema.
> 
> Yes, neither the DTD nor the Schema is normative, and were intended to
> show an example of what such a DTD or Schema should look like.  I will
> ask the WG to look at this again to 1) make sure the DTD and Schema
are
> as consistent as possible, and 2) to make at least the Schema
normative.
> 
> > 2. Why show the DTD when you already show a much more powerful and
> > expressive XML Schema?
> 
> Since it is not normative, the idea was to provide an easy overview of
> the XInclude structure for those familiar with DTDs and less so with
> Schema.  At the time of the first draft, DTDs had a wider audience.
> Now, it may be the case that the Schema is more useful.  I guess I
don't
> see a good reason to remove the DTD at this point though.
> 
> > 3. The Schema shows the <include> element as being able to contain
> > elements/data other than <fallback>.  The spec does not define what
> > happens to those elements/data upon include, e.g.,
> >
> >     <xi:include href="foo.xml">
> >        blah, blah <bar>blah</bar>
> >     </xi:include>
> >
> > Is blah, blah <bar>blah</bar> replaced by the contents of foo.xml
upon
> > include? Is it juxtaposed with the contents of foo.xml? etc
> 
> Section 3.1 says: "The content of the xi:include element may include
an
> xi:fallback element. Other content is not constrained by this
> specification and is ignored by the XInclude processor."  The open
> content model provides for metadata extensibility and new features to
be
> added in later versions.
> 
> > 4. You do not define a serialized syntax (i.e., what a text document
> > would look like after inclusion).  You only define an infoset model.
> > Big mistake, IMHO.  Suppose that on a server I have an XML document
> > which contains <include> elements.  I wish to resolve those includes
> and
> > send the expanded (serialized) document to a client (as a
text/string
> > document).  No way to do it, with this spec.  Example: in the
> > text/serialized version should the top-level included elements have
a
> > fixed attribute, included="true"?  The infoset should have this
> > attribute (e.g., a DOM tree might be able to supply this
information),
> > but should the serialized string have this attribute?
> 
> This seems more like an infoset comment.  Serialization of an infoset
is
> fairly trivial, and just because it isn't covered by this spec doesn't
> mean it isn't possible.  The Canonical XML spec provides one method of
> serialization, although it doesn't preserve all the information of the
> infoset (attribute order, redundant namespace declarations, etc.)
> Personally, I don't see a whole lot of value in standardizing infoset
> serialization - there aren't very many unanswered questions with
severe
> interoperability consequences that would benefit from such a standard.
> 
> > 5.  IMHO, you should just allow xPath expressions, and not allow
full
> > xPointer expressions. (80/20 rule)
> 
> As noted in the draft, we are already worried about requiring full
> XPointer support.  If we don't get enough implementations of full
> XPointer, we will have to scale back to XPath expressions, or even
> farther.
> 
> > 6. Are there any xInclude processors available yet?
> 
> Yes.  LibXML has one (sorry, I'm offline and can't find a link), and
> there are others.  As we collect implementation reports we probably
will
> post them on our group page.
> 
> > My 2 cents.  /Roger
> 
> Thanks, it's worth much more than that to us!
> 
> - Jonathan

Received on Sunday, 16 June 2002 15:33:35 UTC