Hi James, * James Holderness <[EMAIL PROTECTED]> [2006-01-17 19:10]: >>Aggregators which process @type='application/xhtml+xml' as if >>it was @type='xhtml' are in error. Period. > >This argument I don't understand. The spec, while recommending >(super strongly recommending, if you will) that the content >should be a full xhtml document, clearly also allows that "there >may exist valid reasons in particular circumstances [for a >producer] to ignore [that recommendation]". How can an >aggregator that makes allowances for such an eventuallity be in >error?
To recommend conflating `xhtml` and `application/xhtml+xml` is to deprive content producers of precise expressibility of intent. The question is, what does the document mean? RFC 4287 states that saying something is `application/xhtml+xml` means that it is `application/xhtml+xml`. If I ship entries in a feed that are marked `application/xhtml+xml` then I really *mean* they are `application/xhtml+xml` and I don’t want the processor at the other end second-guessing me, thanksverymuch. Now, if you save the string on the following line in a file: <p>Hello world!</p> with an extension of `.html` and open the file in a webbrowser, you are unlikely to a complaint. (Even if it’s `.xhtml`.) This is the point at which the question of whether `application/xhtml+xml` permits document fragments becomes one-third academical. But when I ship `application/xhtml+xml`, I want it treated as a full document, not inline content. That’s why I’m using the MIME type in the first place, instead of saying it’s `xhtml`. I don’t want aggregators to be guessing whether an escaped left angle bracket in my title marks a tag when I’ve clearly labelled the thing @type='text' either. >>Thus, content producers who still follow the 0.3 custom are >>clearly in error too. Period. > >This argument I understand, but I still disagree. I'm willing to >accept that this behaviour is highly discouraged, but it's not a >REQUIREMENT and it's not an error. Try persauding anyone on the >feedvalidator mailing list that SHOULD recommendations should >all be flagged as errors and see how far you get. I'm pretty >sure I'm not the only one that will disagree with you. Of course. Please don’t put words in my mouth; a SHOULD is not a MUST. In fact I myself argued back then that this requirement can only be a SHOULD, because expecting Atom processors to enforce a MUST is nonsensical – no Atom processor is ever going to know whether some content labelled with a MIME type that the processor does not support is valid as the type of content it claims to be. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
