Re: Media types

Tim, (again, sorry for the delay)

> Hm... you're creeping in the direction of deprecating media type
> MIME headers in the case where the resource body is XML.

Not deprecating, just creating a parallel alternative.  But if it's
done well, it could become a 90+% solution.

>  To start
> with, should such a discussion happen at least partly over in the
> IETF?

For sure.  This won't happen without the IETF.

>  I'm a bit nervous - speaking as a person who's written a
> *lot* of in-the-web-server code, I know that in the case where
> something is RDF or XHTML or SVG, I'd rather be able to dispatch to 
> the appropriate handler right there in the server on the basis of
> the headers than have to wake up the general-purpose XML handler
> to figure out the dispatching.  XML parsers are reasonably cheap
> to instantiate, but "reasonably cheap" can become very expensive
> in the context of a high-transaction-volume server, relative to
> the almost invisible cost of reading/parsing a few headers.  

Agreed.  There's no need to prevent custom types from being used
when they're needed.

> Also bear in mind that it's kind of technically tricky to get
> an XML processor to read just the start-tag of the root element
> but not go on to process the whole document  - and since your 
> friendly local SVG/RDF processor probably includes its own XML 
> parser, you're going to end up piping the whole resource body 
> through two XML processors.  Aren't media type headers a better 
> solution?

Yes, but they come with a cost; the cost of registration, and the 
possible cost of a dispatch model inconsistent with the generic
one that needs defining.

> Yes, I agree in principle with the notions that dispatching on
> namespaces is a good thing, and that the namespace of the root
> element of an XML document has a special status, but I'm highly
> unconvinced that serving everything that has XML syntax as
> application/xml is a good direction to take.

Does the above help to alleviate those concerns?  I'm not suggesting we
prevent anybody from doing what they're already comfortable with.  I'm
only suggesting we attempt to define a generic dispatch model triggered
from a generic XML media type, which would likely be useful to lots of
people, especially those working with multi-namespace documents.

> >A related issue is the role of the media type & namespace in content
> >negotiation.  "Accept: image/svg+xml" means something, whereas
> >"Accept: application/xml" means much less (for now).  A benefit of the
> >"xmlns" parameter I've proposed is that it can be used for content
> >negotiation, e.g.
> >
> >  Accept: application/xml; xmlns="http://www.w3.org/2000/svg"
> 
> If the client knows it can process SVG and the server knows how
> to generate it, what's wrong with using the well-established media
> type header mechanism for this content negotiation?  -Tim

Nothing.  If there is a specific media type, then it can be used.  If
not, then this could be used.

I think I'm to the point now where I could write this up.  The big issue
is whether to start with */xml, or to create a new type.  XSLT makes the
former more tricky, but the latter would have the problem of getting
out there and becoming known.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Thursday, 17 January 2002 13:40:18 UTC