ietf-xml-mime
[Top] [All Lists]

Re: Finishing the XML-tagging discussion

2000-03-19 07:04:49
At 08:17 AM 3/19/00 -0500, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
Most of us are of the opinion that indiscriminate sniffing of objects
is a Bad Idea unless you're of the canine persuasion, and that some
form of tagging is a Good Idea.  The question we seem to be hung up on
is whether we should:

a) Use application/xml with Content-Feature tagging.  This would
require more work for some MIME dispatchers to implement up front, but
buys us automatic drop-back to generic XML if added support isn't
available.  Non-upgraded clients would require (possibly) *one*
intervention to add 'application/xml' to their "how to dispatch THIS
one" tables to point at a generic XML application, but there's no
guarantee that added features would be usable, even if installed, if
their MIME handler doesn't do Content-Feature.

b) Use application/foobar-xml.  This apparently requires less work for
some MIME dispatchers to support, at the expense of creating a "rule"
that *-xml is all xml if you don't want to drop back to octet-stream.
In addition, *non-upgraded* clients get to force hand-adding of this
week's foobar-xml to a table of "how to dispatch THIS one" (even if
it's Yet Another 'hand it to our XML application') if they want "better
than octet-stream" handling.

In *both* cases, client software that *has* been upgraded (for either
the *-xml rule or to correctly dispatch based on a content-feature tag)
will be able to hand it off to either a specific featureful XML application
if available, or to a generic XML application if the bells-and-whistles
aren't installed.  However, we're not sure yet which track involves less
total aggrivation for upgrading.

I think that's a reasonable summary of what's going on, and I didn't repeat
the details above it because I think the summary cuts to the heart of the
problem.  (Once sniffing is discarded, anyway.)  We've kicked around a few
times, and mostly kicked it out.  My largest problems with Content-Feature
have to do with human interactions.  There are two aspects to this:

1) Many users have a hard enough time figuring out what MIME Content-Types
are, and adding another layer that only gets use with XML (today, anyway)
is going to be a hard sell to these folks.  Effectively, it's putting a
third layer on to the content type, and doing so in a way that doesn't look
like every other content type.  I'm just not convinced that people will
look past Content-Types.

2) People have grown accustomed to the basic top-level types carrying
meaningful information.  The Content-Feature approach would mean that
Scalable Vector Graphics (SVG) would be application/xml;
Content-Feature=svg  -- not not image/svg-xml.  The contents of those two
descriptions are significantly different, though they purport to describe
the same thing.  This doesn't apply in every case, since a lot of XML
formats belong in application/, but it applies in a significant number of
cases.

The other problem I have with Content-Feature is that it isn't clear to me
- based on my RFC dredgings, which may not be complete - whether or not
there is any kind of registration process or even official status for
Content-Feature.  We've already had several 'acronym collisions' in the XML
world (Steel Markup Language vs. Simple Markup Lanugage, for instance), and
I'd like to make certain these collisions don't all follow us into
MIME-based processing.  (I'm aware that x- is the wild west, but I'd like
to ensure that there's a safer option.)

There have been other objections to parameters along the way, and perhaps
they'll resurface now.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com