W3C home > Mailing lists > Public > www-tag@w3.org > January 2002

Re: Media types

From: Mark Baker <distobj@acm.org>
Date: Mon, 14 Jan 2002 23:00:58 -0500 (EST)
Message-Id: <200201150400.XAA22130@markbaker.ca>
To: tbray@textuality.com (Tim Bray)
Cc: www-tag@w3.org
> At 01:09 PM 14/01/02 -0500, Tim Berners-Lee wrote:
> I'm with TimBL down to here
> 
> >Considering which things,  I suggets that for a namespace wich will be a
> >widely adopted standard and will be used as an outermost element of a
> >document, it is wise but not essential to make a special MIME type. 
> 
> Agreed, but I'd go further.  I'm finding it hard to imagine a situation 
> in which you're defining an XML language in the W3C context but don't 
> expect it sometimes to be served as a web resource.  Given this, it seems
> that the registration of a media type is awfully important.

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 that's a useful criterion.

> >I also think it should be emphasised that when a document is simply labelled
> >as text/xml but uses, at the outermost element, a well-known standard such
> >as XHTML, SVG, SMIL, etc, that any application which purports to support
> >that standard hande the file appropriately, and hopefully in an identical
> >way to the the way it would handle it had a more specific MIME type been
> >used.
> 
> Agreed, but there is no excuse, for example, for a server to serve SVG 
> under any media type other than image/svg+xml.  I'm having trouble 
> imagining a situation in which a server knows a resource body is 
> XML but doesn't know anything else about it.  -Tim

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.

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"

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Monday, 14 January 2002 22:59:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:03 GMT