Re: Media types

> > > It's not MIME's fault that it was designed in an era when no one
> > > expected the possibility of creating such labelled content.  However,
> > > such content is useful, and MIME's inability to handle such things
> > > definitely feels like a limitation from the perspective of people who
> > > like such things.
> > 
> > I don't see an inability of MIME to handle labelled content, I see
> > XML's deliberate decision to use a means of content-labelling which
> > was incompatible with MIME, while still expecting to use MIME
> > framing to convey XML from one place to another.
> 
> How would you have proposed that XML's developers create a
> MIME-compliant form of content labelling?
> 
> Or would you simply have banned the notion of mixing different
> vocabularies into a single document?

I'm not saying that MIME's notion of content-labelling could have 
satisified all of the desired goals for XML; I'm saying that there's
an impedance mismatch between the purposes for which MIME was designed
and the way that XML folks want to use it.  You can think of that as
a limitation of MIME, and in a sense that's true, but the bottom line
is that MIME wasn't designed for that purpose.  And had we tried to
design MIME for that purpose it would have taken several more years
to finish it.
 
> > MIME does have its limitations
> 
> Anything with only two levels is pretty well guaranteed to run into a
> need for three or more.

Some of us think in retrospect that two levels was one too many - 
the top-level has been misused more often than not.  But adding
more levels wouldn't have solved the "mixing vocabularies" problem.

> > On the other hand, it might be worth the trouble to define a
> > different transmission format for the sole purpose of shipping
> > XML around.  It's not as if either SMTP or HTTP is ideal for
> > this purpose either.
> 
> No, they're not very efficient.  I'm not convinced however, that sending
> XML over separate pipes is particularly sensible either.

Nor am I convinced that the existence of HTTP obviates the need for
other applications.  As for "separate pipes", there is no need - 
the pipes that are in place already have a very flexible mechanism 
for multiplexing different kinds of data.  It's called IP.

Keith

Received on Thursday, 17 January 2002 18:21:03 UTC