- From: Ian Graham <igraham@ic-unix.ic.utoronto.ca>
- Date: Thu, 17 Jan 2002 20:51:31 -0500 (EST)
- To: "Simon St.Laurent" <simonstl@simonstl.com>
- cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net
On 17 Jan 2002, Simon St.Laurent wrote:
>
> Sorry to come to this discussion late. (Those reading this on
> ietf-xml-mime may want to visit
> http://lists.w3.org/Archives/Public/www-tag/2002Jan/index.html and read
> the Media Types thread.)
>
> On Thu, 2002-01-17 at 13:41, Mark Baker wrote:
> > >[Tim Bray]
> > > 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.
>
For me, the main points (which simon has nicely captured) for XML and
MIME are::
* using URIs to reference vocabulary definitions
* XML documents can reference multiple vocabulary definition
* The mime mechanism can capture only one of these vocabularies
(note how this dances carefully away from the word 'type' ;-) )
MIME really doesn't give you a nice way of defining multipe properties for
a single resource, other than the media features extension described
in RFC 2912. Using this extension (Designed for a different purpose, BTW)
you could write something like:
Content-Type: text/xml;
Content-features:
(& (primary-namespace="uri1")
(secondary-namespace="uri2")
...
)
The question then is -- does that really give you anything particularly
useful over text/xml+whatever? Once I started to think through some
uses, I honestly couldn't think of a compelling advantage ...
Ian
Received on Thursday, 17 January 2002 21:00:40 UTC