Hi James, * James Holderness <[EMAIL PROTECTED]> [2006-01-17 21:50]: >A. Pagaltzis wrote: >>Aggregators which process @type='application/xhtml+xml' as if >>it was @type='xhtml' are in error. Period. >> >>To recommend conflating `xhtml` and `application/xhtml+xml` is >>to deprive content producers of precise expressibility of >>intent. > >So what is your intent? What do you expect aggregators to do >with that content?
I had to think about this for a while. Really, what I expect them to do with that content is to not fail to display a full document if a full document is what I provide. That aggregators attempt to render such full documents inline (and unsurprisingly fail to produce a reasonable facsimile of the original) is in error. I would further expect that full document to be rendered as is, unadorned by any decorations the aggregator applies to its rendering of inline content and unaffected by any aggregator stylesheets. In other words, I shipped a full webpage in my feed, and I expect it to render as a full webpage in a standalone browser would. To show a fragmentary document inline, I suppose, cannot be argued to be in error. It is still in violation of the spirit of the spec on the producer’s side to provide such, though. >Show it as some sort of document attachment that the user would >have to save to disk and then open up in a separate browser >window? As I said before, most likely, it would be shown in an IFRAME. (This would also provide a local scope for any CSS, thereby greatly reducing the need to cripple any included stylesheet for anti-spoofing reasons.) >My interpretation of the spec is that MIME types are there to >allow for content not covered by the three basic types. So if I >wanted my content to be a pdf document or a jpg (as *inline* >content), I could do so by specifying the necessary MIME type >and encoding them in whatever format the spec required for that >type. Yes, sure, but the whole point is moot because no such thing as a fragmentary PDF or JPEG documemt exists. Either you have a full PDF or JPEG document or you have corrupt, undecodable data. This is markedly distinct from the situation we’re dealing with. >Now your words were that a content producer following 0.3 >customs would be in error. From that I concluded that you >believed the above document would be in error. And since the >only thing I can see wrong with this document is a SHOULD >violation, I assumed you were claiming a SHOULD violation was an >error. Where did my line of reasoning go wrong? Your line of reasoning did not go wrong. I just did not mean “in error” formally as in “producing invalid Atom”. What they’re doing is technically permissible, because it’s not technically disallowable. Replace “in error” by “abusing/misinterpreting the format”, if you want. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
