[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"Well it's all octets so in one sense the processing is the same."
I have to agree with James.
The right questions in my mind is this - how is processing an entry
different from processing a feed with that and 42 entries?
The idea that an entry is a degenerate feed is interesting, but
unsubstantiated. Seriously, i'm not getting it. My experience is the
opposite now, across 3 protocols; feeds are the odd men out (http needs
them to deliver collections) and entries are not subsets of feeds. If
there's real uniformity, I don't see it. To see it, I'd need to see that
feeds and entries are closed under processing, and probably structurally
We've enough field experience that suggests having entries and feeds
sharing a media type is at best inconvenient. I only have to start
thinking about how an APP collection handles partial update failures on
a feed to think I need a dedicated media type for dealing with feeds.
James M Snell wrote:
Well, it's all XML parsing so in one sense the processing is the same.
The key difference arises in how the various documents are used. In my
experience, Atom Entry Documents are nearly the exclusive territory of
APP Clients and push notification services (e.g. Atom over XMPP) while
Feeds generally provide for the redistribution and indexing of entries.
When I parse an entry document, there is no implied feed.
Mark Baker wrote:
Interesting, thanks. But serving different purposes doesn't
necessitate a new media type. What's important is how the two types
of documents are interpreted.
How does your processing of an entry document differ from the
processing of a feed containing (only) that same entry? If processing
the entry is a subset of processing the feed, then you probably don't
need a new media type.
On 11/30/06, James M Snell <jasnell@xxxxxxxxx> wrote:
Mark Baker wrote:
Yes, but more than that. An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata. It's processing is a subset of feed processing. If the
processing or content model of entry is extended, it applies to both
feed documents and entry documents.
Hmm.. I understand what you're saying but I don't think I agree. In the
APP implementations I've put together, Feed and Entry documents
generally serve two entirely different purposes and are usually intended
for two entirely different audiences.