Bob Wyman wrote:
>[snip]
> What you seem to be implying is that the majority of applications
> that process Atom Feed documents are not, in fact, supporting extremely
> important parts of the atom specification. I believe that any properly
>[snip]
Not quite. What I'm implying is that not all applications have the need
to implement the entire specification. Atom Entry Documents and Atom
Feed Documents are each very useful but for different reasons.
> constructed Atom Feed parser will contain all the code needed to parse
> the most complex Atom Entry document. And, an entry document with an
> atom:source is semantically equivelant to an atom:feed with a single
> entry... The problem here is that people insist on building Atom
> parsers that aren't capable of handling more semantics than legacy RSS.
> What we should be doing is encouraging people to exploit Atom and use
> its features -- atom:source among others -- that aren't supported by RSS.
+1 on all points.
> For a parser that properly handles the case of an atom:entry
> appearing within atom:feed, it should be trivially simple code to
> recognize and handle an entry without a feed wrapper. I think there are
> even cases where this makes sense -- and you would even want to
> subscribe to such a thing:
Trivial, yes. That's not really the issue for me.
>[snip]
> In any case, while it appears reasonable (and sometimes efficient)
> for people to subscribe to Entry documents, I don't think we should do
> anything disruptive unless someone can establish actual harm being
> caused by the current state of affairs.
>
The fact that I cannot link to an Atom Entry Document from a browser
without it trying (and failing) to process it as a Feed Document is harmful.
- James
