RE: Architectural problems of the XInclude CR

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 Wednesday, 29 January 2003 16:08:42 UTC