- From: Tim Bray <tbray@textuality.com>
- Date: Mon, 14 Jan 2002 11:15:46 -0800
- To: <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. Of course the practical issue is that this represents real work and that some of it has to be done over in IETF, and can be quite time-consuming. Mind you, the groundwork in 3023 should reduce the level of work required, but it's still real work. >If this >is done, though, I would say it is essential that the "+xml" conventions >from the RFC____ be used so that a generic XML processor can be invoked. Indeed. The +xml syntax is ugly but the reasoning behind it is sound and we should follow 3023 in this respect. >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
Received on Monday, 14 January 2002 14:15:57 UTC