Re: Need an XBL media type

Hi Mark,
I am going to disagree with you and agree with Ian on this one. XBL
typically does not get used as a standalone document format. For example,
you don't double-click on a *.xbl file and expect a special viewer to be
launched, in the same manner as you don't expect a *.css or *.xsl file to
have its own media type and its special viewer. (In fact, XBL is a cousin
to CSS and XSLT used as stylesheets in that it performs a runtime
transformation on source content in conjunction with a host document
format, such as HTML or SVG.) Let's do the world a favor and not require
media type registrations for things for which there isn't much leverage
from the media type registration.

Jon

Jon Ferraiolo <jferrai@us.ibm.com>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865



                                                                           
             "Mark Baker"                                                  
             <distobj@acm.org>                                             
             Sent by:                                                   To 
             public-appformats         "Ian Hickson" <ian@hixie.ch>        
             -request@w3.org                                            cc 
                                       public-appformats@w3.org            
                                                                   Subject 
             01/17/2007 12:33          Re: Need an XBL media type          
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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