Re: Need an XBL media type

Hi Mark,

On Fri, 12 Jan 2007, Mark Baker wrote:
> > >
> > > I believe the spec needs a media type, if only because the TAG 
> > > recommends it[1]. [1] http://www.w3.org/2001/tag/2004/0430-mime
> > 
> > I couldn't find a statement in that document saying that the TAG 
> > recommends that working groups define new MIME types for their 
> > namespace. The document suggests new MIME types should be registered 
> > for new _formats_, but XBL re-uses the existing XML format, so that 
> > doesn't apply to XBL as far as I can tell.
> 
> The previous version of the finding used the term "language"; I'm not 
> sure why it was changed to "format", but I don't recall any discussion 
> which suggested the TAG was ok with "application/xml" for all XML.

I can't speak for the TAG either.


> That finding was authored in response to an issue raised by me on behalf 
> of the XML Protocol WG, asking if/why SOAP needed a SOAP-specific media 
> type.  The advice we received was yes, we do.

While I could see use cases on a per-language basis that might justify 
MIME types for certain languages, it seems not without risk to establish a 
blanket policy that all languages should have MIME types. Some languages 
don't need MIME types, some do.


> > 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 -- 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.

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.

I could imagine that SOAP would have different requirements since 
(presumably) it is not treated in a generic XML fashion, and requires more 
than per-element namespace dispatch to be processed (e.g. it requires that 
the XML parser be hooked up to a SOAP-specific consumer before the parsing 
is started). However, this is not the case with XBL, where a generic 
processor "Web" processor is expected (that is, a generic parser that 
creates a DOM and implements DOM Core and related APIs), and where, in the 
absence of a "Web" processor, XBL might as well be treated as generic XML 
since it would not otherwise be useful.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 12 January 2007 22:03:59 UTC