Re: Media types

At 11:00 PM 14/01/02 -0500, Mark Baker wrote:
>If by "served" you mean that it's a possible representation of some
>resource, then what about SOAP?  I don't ever expect to see a SOAP
>envelope on a GET response.

I'm not sure I'm as confident as you are that this won't happen,
but I suggested that we require a media type unless there's a powerful
reason not to; this sounds like an example of the powerful-reason case.

>I have no problem with people serving up SVG as application/xml.  It
>will likely not work as well as doing it with image/svg+xml, yet, but
>that's the problem of the server admin.  Given that application/xml + a
>namespace is supposed to behave identically to a specific media type
>(I agree with TimBL here), I don't see why we shouldn't permit server
>admins to exert some pressure on clients to ensure that becomes the case
>over time.  Permitting any XML content to be delivered as
>application/xml (note to Norm; text/xml should die die die 8-) will do
>just that, I believe.

Hm... you're creeping in the direction of deprecating media type
MIME headers in the case where the resource body is XML.  To start
with, should such a discussion happen at least partly over in 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.  

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

>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

Received on Tuesday, 15 January 2002 13:40:49 UTC