Re: Media types

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday, January 26, 2002, at 12:29 , Steven Pemberton wrote:

> Our opinion then was that media types were Not Very Useful for 
> heterogeneous
> documents, and that application/xml would have to do, with namespaces 
> doing
> the rest.
>
> But the message from Norman Walsh has truly warmed my heart::
>
>> From: Norman Walsh <Norman.Walsh@Sun.COM>
>
>> In general, is there really any value in declaring specific media
>> types for XML vocabularies?
>>
>> Imagine that I've got text/foo+xml and text/bar+xml. If I send a
>> document that's just 'foo' or just 'bar', those may have value. But as
>> soon as I start mixing foo and bar together, I don't see that there's
>> any right answer as to what media type I should use.
>
> If we can now finally agree that XML documents can be classified with
> application/xml and let the namespaces do the rest, the HTML WG will be 
> more
> than delighted to go back and sweep up the mess!

Although there is no absolute perfect answer for any of the 
heterogeneous documents I believe that the media type should be the 
outermost element. This may be mostly meaningless in a transport 
protocol such as SOAP but at least the application knows it must support 
SOAP. This is useful when determining how to view a document from a mail 
application or browser.

Currently support in browsers and mail clients is all based around mime 
types. Sure, as time goes on we may see far more built in XML namespace 
into these applications, especially browsers. MIME is the current 
standard though.

Tim Berners-Lee wrote:

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

Like Tim says about the outermost element should be the MIME type for 
standard (registered) types.

Examples have been given like - xyz browsers supports XHTML but not SVG. 
But if the SVG is NOT contained, just in an image tag, then the browser 
still only knows that it is XHTML. This is correct, but I would argue 
two points here:

	- Browsers send what they support and servers are expected to 
respond with only documents that support the types they support. This is 
not very well supported, but it is part of the protocol. That way a web 
server can decide to render a SVG into a PNG (or use a cached version) 
and return that if SVG is not supported.

	- XHTML still works without the SVG section. Sure some pages may be 
meaningless, especially if the point is around the diagram.

My point here is that my application decides that it is going to support 
XHTML then if other formats are contained within the XHTML document, I 
can deal with them gracefully. But I may not write it to support 
MyXMLThing which can contain XHTML documents.

Tim Berners-Lee wrote:

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

Tim also writes here that applications should support both correctly. 
This seems reasonable, but it does muddy the waters a little. If the 
application must support text/xml (application/xml) then why support 
MIME as well. Is there an advantage is supporting both. If by having the 
MIME type in the standard applications can choose to use that format, 
then they will not be compatible with another server which has chosen to 
use just application/xml.

Scott

- ---
Scott Penrose
Open source and Linux Developer
http://linux.dd.com.au/
scottp@dd.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE8UdGuDCFCcmAm26YRAr9dAKCWhfeWJjrIBeLtUn5dhvrWg6RaTQCdHGIf
j2FsSmqSAywXljqnjYzF6AM=
=AVuj
-----END PGP SIGNATURE-----

Received on Friday, 25 January 2002 16:44:39 UTC