W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > April 2002

RE: Comments on XInclude

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Sat, 6 Apr 2002 08:29:38 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C0589BE1F@red-msg-08.redmond.corp.microsoft.com>
To: "Roger L. Costello" <costello@mitre.org>, <www-xml-xinclude-comments@w3.org>
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
> 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

> 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 Saturday, 6 April 2002 11:30:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:56 UTC