W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > January 2003

RE: Architectural problems of the XInclude CR

From: Martin Duerst <duerst@w3.org>
Date: Thu, 30 Jan 2003 15:01:40 -0500
Message-Id: <>
To: "Simon St.Laurent" <simonstl@simonstl.com>, www-xml-xinclude-comments@w3.org, www-tag@w3.org

I think the first paragraph is fine. I don't like the references
to specific products at the start of the second paragraph.

What about changing the first sentence of the second paragraph to:

A raw XML version, an SVG version, an XSL-FO version, and an XHTML
version of the same content, as well as different versions in
different languages, all potentially using the same ID values,
can easily be obtained with mechanisms like HTTP content negotiation.

Regards,    Martin.

At 16:09 03/01/29 -0500, Simon St.Laurent wrote:

>Paul Grosso writes:
> >In this week's XML Core WG telcon, we discussed these comments,
> >but no one on the call could figure out what kind of wording we
> >might put into the XInclude spec about content negotiation.
>How about:
>The use of mechanisms like HTTP content-negotiation introduces an
>additional level of potential complexity into the use of XInclude.
>Developers who use XInclude in situations where content negotiation is
>likely or possible should be aware of the possibility that they will be
>including content that may differ structurally from the content they
>expected, even if that content is XML and corresponds to the fragment
>identifier used.
>Technologies like Cocoon and AxKit (not to mention XSLT) make it far
>easier for a single site to return, for instance, a raw XML, an SVG, an
>XSL-FO, and an XHTML version of the same content, all using the same ID
>values.  Developers whose XInclude processing depends on the receipt of
>a particular vocabulary of XML should be aware that the mechanisms for
>specifying those vocabularies are separate from XInclude.  To keep
>things simple, document creators using XInclude should refrain from
>referencing URIs that can return more than one kind of representation.
>I think that qualifies as a fix-in-documentation with no change to the
>functionality of the spec.  Developers who find their programs including
>XHTML instead of XML or SVG will have been warned.
>Simon St.Laurent
>Ring around the content, a pocket full of brackets
>Errors, errors, all fall down!
>http://simonstl.com -- http://monasticxml.org
Received on Thursday, 30 January 2003 15:19:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:32 UTC