RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?)

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> > More specifically, what happens when the XML-dispatching program decides,
> > "Surprise! The original client is the agent best suited to display of this
> > particular XML object." The problem is that even in tightly integrated plug in
> > setups there's usually no way to communicate this sort of thing back to the
> > client's dispacher to the point where a truly seamless display can be
> > achieved.

> > The inevitable result is suboptimal integration, which users, myself included,
> > loathe.

> I can't agree with you here. Yes, Eudora does this badly, but I think this
> is a problem with the implementation, not the idea. If an MUA or Web
> display engine says "I can natively display a stream of XML", then the
> integration with an intermediary is not difficult at all.

Actually, in my opinion Eudora is far and away the best agent out there when it
comes to this sort of thing, which is why I held it up as a fairly unique
counterexample to what I see as the current state of affairs. Nothing else I've
seen even comes close to having Eudora's capabilities.

If you know of something else I'd like to hear about it.

> > This is another instance of a problem we first encountered with security
> > multiparts: When you dispatch handling of a security multipart to a separate
> > application, getting the enclosed data back to the original client often
> > isn't possible. And while a few clients have adopted plugin architectures
> > that address this (Eudora, for example), most have not, and worse, plugins
> > capable of working really well in such environments have been slow in coming.

> I've spoken with people who make such plugins (such as the ones I try to
> use with Eudora), and they complain about the Eudora API, not about their
> ability to hand back blobs of text to the program. In my mind, this can't
> be all that hard for data types that the original program knows how to
> handle, particularly if they are guaranteed not to get back a multipart.

Well, as it happens I'm familiar with the Eudora API -- I was asked to review
its capabilities in this area some time back, and I liked them so much that I
modelled some aspects of a similar API in our product after what Qualcomm had
done.

So while I cannot claim to have actually written code to the Eudora API, I can
claim to have developed a similar API and written code that uses it to do
similar things. And I can assure you that not only are such transformations
possible, they are easy to implement using APIs of this sort.

So I'm afraid I'm not prepared to accept the complaints you have heard as 
valid. Perhaps they were directed at an earlier version of Eudora, or something
like that.

(Please note that I don't work for Qualcomm and I only use Eudora rarely. So I
have no vested interest in their MUA.)

> To me, the problems of "original clients" displaying XML handed back to
> them from a process that decides what goes where isn't a serious issue. The
> more serious issue in my mind is that we are starting to get a significant
> number of XML formats and some viewers, and we haven't agreed to a method
> for them to link those through MIME. I think we need to say "yes, MIME is
> your linkage and here's exactly how" (which I don't think we are ready to
> do), or we must say "MIME is not your linkage and you need to come up with
> your own methods."

Again, I don't think you can say either one is right in general. I think that
for some applications separate MIME types are appropriate and necessary; for
others a single MIME type for an entire family of things is appropriate; and
for others a generic MIME label is fine.

				Ned