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(_at_)imc(_dot_)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