[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Finishing the XML-tagging discussion
> 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
It isn't just the dispatchers that have to be upgraded, but also the MIME
object label generators. That is, you have to upgrade both the sending and
receiving system for this to work, since a lot of existing labelling systems
don't have the ability to generate content parameters or a content-feature
field. And unless you upgrade the sender, you're stuck with either generic XML
handling or possibly even octet-stream handling.
This also doesn't make it clear how hard the dispatcher upgrade is in this
case. This isn't some simple tweak to the underlying code -- in many cases a
redesign of the user interface will be necessary to add the ability to specify
control-by-parameter or control-by-content-feature.
And there's also the issue of how you make this work in contexts where MIME
types are used but content parameters or content-feature expressions are not
allowed. (Such uses exist in various popular HTML hacks, for example.) While
you can argue that such usage is broken, it nevertheless exists and is widely
used. So now you are faced with having to redesign a bunch of protocol, much of
which we have no say over, and where way to do it in some cases isn't all that
obvious, and fix these implementations as well. Frankly, I don't think this is
ever going to happen. What will happen is that XML format developers will
continue to insist on registering specific media types, and there's absolutely
nothing in our rules that says they can't.
> 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.
Experience with similar issues surrounding multipart/signed say it
won't be usable. (Unforunately with multipart/signed there was no
> 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.
And the latter can be (and often is in practice) done with the assistance
of a "configuration wizard", making the process relatively painless even
for inexperienced users.
> 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.
We're talking about a process that requires fairly complex sender and receiver
upgrade, as opposed to one that requires a relatively simple receiver upgrade.
The comparison leaves me with little doubt as to which is easier.
> Have I mis-stated any major points of the two camps?
Mis-stated, no, but stated incompletely, yes.