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

> > > 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.

The point is that there is a use driven by a need. Your statement
that "text/html has proved to be of no value whatsoever" is simply
false. The fact is that text/html (while being used in ways other
than strictly intended), has served a tremendous use in allowing 
people to exchange richer email messages than text/plain.

> 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.

"unnecessary" != "no value whatsoever"

The community adopted text/html because they weren't presented
with any other mechanism (or at least, the alternatives weren't 
presented anywhere nearly as clearly or forcibly). The community
made great use out of it.

> > 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.

I agree. I think *the* mistake (at the MIME level)with HTML 
is *not* text/html, but rather one of specification and under 
education: text/html could have been registered, and the 
specification could have clearly stated that alternatives 
existed for use when the amount of markup rendered the message 
essentially uninterpretable.

That said, I would argue that the real mistake is in abusing
HTML in the first place, but that practise is well established 
now.

> Because it isn't what we told them to do. We told them to use 
> text/html, so that's what they did.

Right. They were not presented with a choice, and *that* is the
historical mistake.

> But we also said that the HTML had to be legible. That didn't 
> happen.

Sure, but what else could have happened? Vendors were shoe-horning
HTML support onto existing tools, and there was a marketing need to
get products shipping with support for exchanging HTML content.

> The point is now we know better, so we should not let it happen 
> again.

I strongly agree with you. That to me means presenting 

  1) choices for types
  2) clear guidelines on their use.

I have faith that when presented with those two things, developers
will do what is right.

> I believe my argument discounts it quite effectively.

Well, belief is a very personal, very subjective thing. I do *not*
believe your argument discounts it at all. Your arguments seem to
me to be an overreaction to something I think we can all agree is
less than perfect.

> In addition, I haven't noticed a lot of support for other 
> quarters for your approach.

Perhaps people are just tired of debate and are moving with their
feet? XML 1.0 *has* been around for a long time, and SGML, even
longer.

Developers come to the IETF looking for guidance in standards
conformant deployment. In lieu of a standard, a draft will 
suffice. In lieu of a draft, rough concensus will suffice.

I think the developer community has largely already made up 
it's mind.