[Redirected - This came to me via ietf-822(_at_)imc(_dot_)org, but it belongs
here as
well. I'm not sure the author is subscribed to ietf-xml-mime. - Simon]
On Sat, 18 Mar 2000 10:58:48 EST, "Simon St.Laurent"
<simonstl(_at_)simonstl(_dot_)com> said:
I meant this within a framework of XML processing that goes beyond generic
document+style sheet->presentation. There are many document-oriented
applications out there where application/xml or text/xml is perfectly
appropriate and does what their users need them to do.
OK.. If I'm interpreting what you said here, it's that many document-oriented
XML objects can be tagged as {application,text}/xml and sent out the door,
and that will suffice.
Some of these may eventually develop the need for more specific MIME types,
of course, but lots of them will likely stay in application/xml or
text/xml. Having the -xml suffix would also ease the integration of these
new MIME types with other XML documents.
The main argument continues to hold for XML formats that receive more
specific automated processing.
Now, based on another message that preceeded this, I think we agree
that "some XML objects could utilize further tagging because sniffing
around the inside of objects becomes ugly". What's unclear (at least
to me, at the moment I write this) is whether you are specifically
advocating tagging such things with 'application/foobar-xml' or whether
just iterating that some tagging (possibly via Content-Feature: or
whatever) is needed. Here, you seem to be saying -xml suffixes are
a Good Idea (and making a good case for it). However...
On Sat, 18 Mar 2000 10:38:18 EST, "Simon St.Laurent"
<simonstl(_at_)simonstl(_dot_)com> said:
I've been dreaming about that for a while. Connect it to an editor, and I
know a lot of people who'd love to buy the product. Even if I didn't have
an SVG editor handy, or some kind of generic image tool, I could tell the
browser to pass it to my preferred XML editor - Notepad, XMLSpy, XMetaL,
whatever - on grounds that the suffix suggests its possible.
I wonder what it would take to build that into Mozilla? Hmmmm....
If you go the "application/xml; Content-Feature=foobar" route, you're
DONE. You don't have the added support handy, it just drops to
wherever you configured Mozilla to pass the stuff. The grounds that
"its possible" here is that it's tagged as 'application/xml', which
should be sufficient for tagging that it's possible. This is actually
*less* work to make work under Mozilla, at the expense of *not* passing
along a hint to Notepad/XMLSpy/whatever that it's a *FOOBAR* xml, not
just a generic xml.
<taking a deep breath>
To summarize:
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.
Have I mis-stated any major points of the two camps?
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech