Re: Media types

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@imc.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@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Thursday, 17 January 2002 16:10:58 UTC