Simon,
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.
Definitely. Though what I'm proposing should ruffle the feathers of any
media type folk, I wouldn't think. I'm not proposing anything like
"+xml", just a (possibly) new media type for XML that would be used to
describe content which follows certain rules about how it expects to be
handed to processors bound to namespaces.
Mark earlier proposed:
application/xml; xmlns="http://www.w3.org/1999/xhtml";
I like to think that I "tossed it out for discussion". I have
reservations about it myself[1].
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 haven't given these the attention they deserve yet. Perhaps I'll
just write down what I'm thinking (an I-D is under way) and let others
add to it.
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?)
Almost exactly what I was thinking. My strawman media type was
application/xmlns-dispatch+xml (not very catchy, I know). But it would
really help its chance for success if we could bind this behaviour to
application/xml. XSLT makes that tough, but it would be worth digging
to see how common this use of XSLT is (I fear it's common).
Alternately, it could be bound to "+xml", but we'd have to check to see
that it's consistent with deployed processors. Also, it might be
confusing to people (or just plain wrong?) if "+xml" is used to specify
this behaviour, but */xml is not.
I'll start with a new media type.
and a header or parameter or
plural thereof to identify namepace URIs.
I'm not so sure. I expect lots of discussion about this point though.
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.
Let the games begin! I'll try to have my draft out shortly, but my time
has been at a premium recently. Luckily it should be a short draft.
(There may also have been an Internet-Draft about this at some point,
but I don't remember where/if it went.)
Hmm, I don't recall one but I could have missed it.
[1] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0070.html
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca http://www.planetfred.com