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

RE: text/xhtml+xml vs. application/xhtml+xml

2000-10-31 21:09:14
But the  analogy is gravely flawed in any case -- text/html
has proved to have no value whatsoever. And this goes far
beyond the notion of "good" and "bad" use.

I think the millions of messages sent using text/html would
disprove the notion that "text/html has proved to have no value
whatsoever".

Actually, the type's use proves nothing, since as I pointed out previously, it
isn't necessary to use the type to get the right effect.

It seems to me that you are projecting a subjective
analysis. It's fair to say that text/html is not being used as
intended. That is not the same as saying it is of no use.

And you are arguing a strawman here. I never said that sending HTML
was of no use, only that the labelling of it as text/html was and
is unnecessary.

Anyway, the genie *is* out of the bag.

For HTML it is. Doesn't mean it is out of the bag for other types. We should
learn from our mistakes.

because again, of (supposed) interoperability, and because they
didn't have any escape route.

Sure they did. Application/html combined with a content-disposition
label of "inline" offers all the benefits and has none of the
problems.

If that is the case then why didn't the MUA's adopt this?

Because it isn't what we told them to do. We told them to use text/html, so
that's what they did. But we also said that the HTML had to be legible. That
didn't happen.

Again, I'm not blaming anybody for this. It happened, it was a mistake, or
an expectation mismatch, or whatever else you want to call it. The point
is now we know better, so we should not let it happen again.

With HTML, the genie is already out of the bottle, but with XML
there is a chance to get MUA's working as they should: when
sending textual data, use text/xml, but when sending application
specific data, send application/foo+xml, etc.

In case it isn't obvious, I am strongly opposed to this policy.

It's obvious, but that doesn't discount it.

I believe my argument discounts it quite effectively. In addition, I haven't
noticed a lot of support for other quarters for your approach.

                                Ned