- From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Date: Wed, 7 Jan 2004 14:43:02 -0500
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: "Dan Connolly" <connolly@w3.org>, <www-xml-xinclude-comments@w3.org>, "Ian Jacobs" <ij@w3.org>
At 11:13 AM -0800 1/7/04, Jonathan Marsh wrote: >Perhaps my second draft is better? > ><note> > <p>A key feature of XInclude is that it allows a resource to be >cast to a user-specifed type for inclusion (XML or text). That doesn't sound 100% accurate to me. It implies other things like "image/jpeg" or "text/rtf" can somehow be cast to XML. I'd prefer to make the sentence more specific and avoid the word cast, something like A key feature of XInclude is that it allows a resource to be treated as text/plain instead of its declared MIME media type. >When I describe the problem that way, there is an improvement we could >make. We could say that if the returned media type is actually >application/xml or text/xml, the fragment syntax is interpreted as an >xpointer, and a separate xpointer attribute is not necessary. Resources >returned with other media types rely on the xpointer attribute. As an implementer this strikes me as very messy. I'm often reading a document out of a file or an InputStream that does not have an available MIME media type. Nor do I much want to have to have complicated web 2^N options depending on whether there is or is not an xpointer attribute, is or is not a fragment identifier, is or is not a MIME type, the MIME type is or is not XML, etc. -- Elliotte Rusty Harold elharo@metalab.unc.edu Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Received on Wednesday, 7 January 2004 15:27:14 UTC