Re: Need an XBL media type

Ian,

On 1/12/07, Ian Hickson <ian@hixie.ch> 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

Received on Wednesday, 17 January 2007 20:33:19 UTC