- 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