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? 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? Right
now I'm displaying "appliction/xhtml+xml" documents inline (as do many other
aggregators). That happens to involve exactly the same process as displaying
type="xhtml" content inline. You're saying that that is an error, but I
don't see anything in the spec that substantiates that assertion.
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.
This has got nothing to do with second-guessing. Just pretend for a moment
that there was no such thing as the "xhtml" type. Now the question is what
is the correct way for an aggregator to display an "application/xhtml+xml"
document. There's nothing in the spec that says an aggregator can't display
that document inline. That's not second-guessing, that's an implementation
choice. The fact that displaying such a document inline turns out to involve
the same process as the "xhtml" type is irrelevant.
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`.
That's not an entirely unreasonable interpretation of what the spec might
mean, but it's not the only interpretation. 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.
A really smart aggregator would probably have built-in support for several
common types, perhaps have plugins for less common types, and worst case
fall back to saving to disk when it knows nothing about the type at all
(much like web browsers and email clients). If I specifically wanted to
include content that should be rendered out-of-line or displayed as an
attachment, I would use an enclosure link.
Following my reasoning, application/xhtml+xml documents are just another
extension type for which I happen to have built-in support and can be
rendered inline.
Thus, content producers who still follow the 0.3 custom are
clearly in error too. Period.
Of course. Please don’t put words in my mouth; a SHOULD is not a
MUST.
My apologies then. I've obviously misunderstood what you're saying. The
example feed shown below is using what I believe to be 0.3 customs (i.e. the
type set to "application/xhtml+xml", but the content is not a complete xhtml
document):
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom";>
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<content type="application/xhtml+xml">
<div xmlns="http://www.w3.org/1999/xhtml";>Some text.</div>
</content>
</entry>
</feed>
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?
Regards
James
