[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> > It isn't a question of blame, it is a question of whether or not
> > agents have been generally able to construct HTML objects that
> > are legible without any formatting. In hindsight, the answer to
> > this question has proved to be "no". And since text/html's
> > utility was predicated on the answer being
> > "yes", it was a mistake to have defined it.

> I disagree with the logic here: it's like saying that the creation
> of weapons is predicated on their being put to good use, but having
> seen them kill people, the creation is a mistake.

Actually, a fair number of people make precisely this sort of argument in
regards to weapons and consider it entirely valid. 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.

> At the end of the
> day, it is the responsibility of the agents to label the content
> correctly... you can't hold the tools creators responsible for
> their misuse.

Again, you're focusing on blame. Blame isn't relevant.

> If the agents consistently abuse the protocols and standards, then
> there is an argument that the agents needs aren't being met.

Perhaps, but in such cases the right answer is to propose new mechanisms that
do meet the agent's needs, not to repeat mistakes we've made in the past.

> is abused because people needed the equivalent of RTF, but wanted
> to piggyback on the (supposed) interoperability/business benefits
> of WWW standards.

> Likewise, agents consistently send data as text/html when in
> reality, the content is application/x-whatever. The main reason is
> 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.

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