Subject: RE: text/xhtml+xml vs. application/xhtml+xml - msg#00049

Previous Message by Date: click to view message preview

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

> This is a subtle issue that very few document creators will > understand True, but then the argument against text/html is also rooted in such subtlety? > It's much better to pick one MIME type for each media type then to try to > pass on the decision to folks who won't understand or won't care about the > subtlety. That one type, IMHO, should almost always be application/foo+xml > not text/foo+xml. In that case it would seem much better to define application/foo rather than application/foo+xml XML is a complex object type (as is text in general), the question is where that complexity best resides, and where one desires interoperability. I would argue that text/xml (as in my example) is useful, but not sufficient because it doesn't capture everything needed to process the content. This is one of the problems that XML brings to the fore because it can represent so many things, and be interpreted in so many ways (MIME is built around the assumption that the media type canonically defines how it should be processed). To get back to ground zero, one must ask why one is exchanging XML in the first place. If is as a structured peice of text, then text/* is fine. More often than not, this will *not* be the case, and so there is a good argument for application/*. In cases where XML content is being served with additional defined processing, the message type will probably be a multipart message, with one part being labelled as text/xml (another might be application/xsl or text/css). Bottom line: XML in well-defined cases should use XML, otherwise it will probably use a multipart message.

Next Message by Date: click to view message preview

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

> > This is a subtle issue that very few document creators will > > understand > True, but then the argument against text/html is also rooted in > such subtlety? The subtlety doesn't lie in the intent, but in the difficulty of achieving it. You can construct HTML that can be read without an HTML processor of any sort. But few if any agents that emit text/html actually do this. Instead they emit junk that is quite difficult to read even if you're familiar with HTML, and nearly impossible if you aren't. > > It's much better to pick one MIME type for each media type then to try to > > pass on the decision to folks who won't understand or won't care about the > > subtlety. That one type, IMHO, should almost always be application/foo+xml > > not text/foo+xml. > In that case it would seem much better to define application/foo rather > than application/foo+xml No. There's a specific purpose to the +xml suffix and it should be used when it is appropriate. > XML is a complex object type (as is text in general), the question is where > that complexity best resides, and where one desires interoperability. I > would argue that text/xml (as in my example) is useful, but not sufficient > because it doesn't capture everything needed to process the content. This > is one of the problems that XML brings to the fore because it can represent > so many things, and be interpreted in so many ways (MIME is built around > the assumption that the media type canonically defines how it should be > processed). This isn't necessarily true in light of the definition of the +xml suffix. In addition, there is more to it than this. Top level types in particular are intended to tell you generally how something is or can be processed. This can assist an agent in handling material even when a specific definition isn't available. > To get back to ground zero, one must ask why one is exchanging XML in the > first place. If is as a structured peice of text, then text/* is fine. No it isn't, because that's not what the top-level text type is for. The intent of the text type is to label material that can sensible be presented to people without any processing. You seem to think that the top-level text type label is intended to label structured text, but that's just not what it is for. > More > often than not, this will *not* be the case, and so there is a good argument > for application/*. In cases where XML content is being served with additional > defined processing, the message type will probably be a multipart message, > with one part being labelled as text/xml (another might be application/xsl > or text/css). > Bottom line: XML in well-defined cases should use XML, otherwise it will > probably use a multipart message. The +xml suffix is intended to make XML detectable even when the specific type isn't known. This eliminates the need to use application/xml to insure such processing is possible. Ned

Previous Message by Thread: click to view message preview

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

> I completely agree with Keith. Text/html was a mistake. That's like saying richtext was a mistake. The fact is that the MUA's are blindingly violating the HTML specification and making it an application-specific format. You can hardly blame text/html for that.

Next Message by Thread: click to view message preview

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. 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. If the agents consistently abuse the protocols and standards, then there is an argument that the agents needs aren't being met. HTML 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. 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.