Ian,
On 1/12/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > What would the use cases be for a new MIME type that couldn't be > > handled by application/xml? (Consider in particular that XBL's > > processing model is defined in terms of handling any DOM, not in terms > > of handling HTTP payloads or similar.) > > Any use case which follows the findings of the authoritative metadata > finding with respect to using external metadata to determine the > semantics of the payload (i.e. no sniffing); > > http://www.w3.org/2001/tag/doc/mime-respect.html But XBL already handles those cases with a generic XML MIME type --
But using a generic XML media type doesn't license a recipient to infer XBL (or SVG or XHTML or any XML vocabulary) semantics. It says "this is XML" which is akin to sending HTML as text/plain (or text/sgml I suppose) and still rendering it as HTML. There's even a section in RFC 3023 which warns against this interpretation. I helped write it (blame Larry for its lameness though 8-); An XML document labeled as text/xml or application/xml might contain namespace declarations, stylesheet-linking processing instructions (PIs), schema information, or other declarations that might be used to suggest how the document is to be processed. For example, a document might have the XHTML namespace and a reference to a CSS stylesheet. Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing.
in fact, the XBL specification _requires_ no sniffing and defines processing for _any_ situation in which a DOM is created, whether from XML, from script, or from another format (e.g. a hypothetical namespaced JSON node tree). The use of XML is secondary to XBL, which is a DOM-based technology, and isn't, in fact, required.
If you dispatch an XML document labelled as */xml (or any unknown */*+xml type) to a processor based on namespaces, then that's sniffing because it's using embedded metadata to infer contained document semantics. Even if it were licensed, which it isn't (although I agree that some browsers agree on interpreting those documents that way[1]), it's still sniffing, so there's still advantages (e.g. security) to supporting an approach which doesn't require sniffing.
Thus I think the wording of the TAG finding you originally quoted is spot on -- formats need MIME types, so that you can determine which parser to use. For example, whether to use an XML parser, an HTML parser, a JSON parser, an ECMAScript parser, a CSS parser, and so forth. But once the parser has been selected, further information is not required, since it can be determined without heuristics from the resulting parsed tree, or from the syntax. For example, XML 1.0 and XML 1.1 can safely share a MIME type since the syntax unambiguously determines which is in use, and thus the parser can, without undefined "sniffing" heuristics, determine which parser mode to use. Similarly, once XML has been selected as the format, the namespace information unambiguously determines what processing model to apply to the nodes in the resulting DOM tree.
Another thing to keep in mind is that XML and XML namespaces are independent specs, and one needn't author XML using namespaces. In such a case there is no option but to use media types specific to the vocabulary (and an external-metadata supporting envelope, such as MIME multipart). Using namespaces shouldn't change that for the reasons given in the TAG's authoritative metadata finding (regarding external metadata). Cheers, [1] http://www.markbaker.ca/2004/01/XmlDispatchTest// Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
