- From: Simon St.Laurent <simonstl@simonstl.com>
- Date: 17 Jan 2002 16:05:09 -0500
- To: www-tag@w3.org
- Cc: ietf-xml-mime@imc.org, mura034@attglobal.net
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. It would be difficult for such a thing to happen without the IETF, but making changes to MIME of any fundamental sort is intensely difficult. Despite the work I put into RFC 3023, and the very rough consensus we managed to achieve there, I think XML is demonstrating the limitations of MIME on a regular basis. I wrote briefly about this last year (http://www.xml.com/pub/a/2000/06/21/disruption/index.html), but suspect that it may be time to move past two-part MIME Content-Type identifiers entirely, and start moving toward identification approaches which are capable of supporting the diversity XML makes possible. It seems like XML is effectively using URIs for vocabulary identification, though this isn't entirely explicit in the namespaces specification. The problem with the compromise we managed to reach on ietf-xml-mime during the RFC 3023 work is that even image/svg+xml or application/soap+xml doesn't say enough to make clear decisions about the nature of a document without actually reading it. We did what we could under the historical, technical, and political circumstances to communicate as much information as possible. Mark earlier proposed: application/xml; xmlns="http://www.w3.org/1999/xhtml" It's a good idea, but only a start, given all the possibilities of that XHTML document's content. I don't believe the "root namespace" is an adequate identifier. Beyond that, I worry about lots of cases where a namespace may appear in a document, and an application needs to understand its use, but only some of its functionality is used. XLink is a great case of that, as most implementations I've encountered focus only on simple linking, and leave off the more complex stuff for now. XSLT provides a lot of interesting and difficult cases as well. RDDL (http://rddl.org) may be an important ingredient in the mix. > > Yes, I agree in principle with the notions that dispatching on > > namespaces is a good thing, and that the namespace of the root > > element of an XML document has a special status, but I'm highly > > unconvinced that serving everything that has XML syntax as > > application/xml is a good direction to take. > > Does the above help to alleviate those concerns? I'm not suggesting we > prevent anybody from doing what they're already comfortable with. I'm > only suggesting we attempt to define a generic dispatch model triggered > from a generic XML media type, which would likely be useful to lots of > people, especially those working with multi-namespace documents. If that is to happen - and I think it would be a good thing - I'd much prefer such information appears in metadata provided before an application goes to the trouble of downloading a document. More information sooner is - I think - always going to be the better option. For now, that means MIME types like image/svg+xml rather than plain old application/xml, if only because both graphics programs and XML processors will be happier. Documents containing multiple namespaces are a substantial challenge to the foundations of MIME content types. It may be that we need a new MIME type (application/extensible+xml?) and a header or parameter or plural thereof to identify namepace URIs. Getting there will require a lot of long but worthwhile discussions at the IETF. ietf-xml-mime@imc.org is the place to start that. (There may also have been an Internet-Draft about this at some point, but I don't remember where/if it went.) -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
Received on Thursday, 17 January 2002 15:01:35 UTC