RE: more on the simplified feed format

[Ziv Caspi <zivca@xxxxxxxxxxxxxxxx>]

Seairth Jacobs wrote:

> >1. Replace the use of @etag with that of <modified> which we already
have.
> >
> >
> Note that in SSFF[1], I indicate that etag can be the modified
> timestamp, if you desire.  Or it can be an etag, a sequence number, a
> revision-specific URL, etc.  Now, I agree that the name may not be the
> right one, but I do not think it should be changed to a <modified>
> element.

Fine. Let's call that <timestamp> (or @timestamp).

> I think that the <link rel=""/> format makes the most sense, at least
> given the current conversations going on.

I have no objection to that, as long as the relation type be
intuitively-named (see also my reply to Ken).

> >3. There's absolutely no reason to force producers to have their feed
> >structured in only a couple of ways (full feeds vs. linked feeds). The
goal
> >should be to allow a feed resource to include any subset of
metadata/content
> >that the feed producer feels comfortable with.
> >
> To what advantage?  Do feed producers (not the application developers)
> really care whether the metadata is in the feed or in a separate
> document?  Is there really a perceived advantage (again, to the
> consumers) to allowing arbitrary amounts of entry metadata to be
> duplicated in the feed as well?

Yes, certainly. The battle is between functionality and resource usage (on
both sides -- both consumers and producers). I do not think we can say in
advance that only the two extreme "work points" are relevant.

> > Thus, an Atom feed resource
> >could include for each entry the id, linkToEntry, modified date, title,
> >abstract, and still provide full entry content (not just the content
> >itself!) in some retrievable URL that can be consumed by aggregators.
> >
> >
> This also means that feedreaders must always look in two places to look
> for all of the information.  Otherwise, knowing that the information
> will also be in a linked-to entry document, I would think that the
> feedreaders would skip looking for that information in the feed and only
> look in the entry.

I can certainly think of consumers who would configure their aggregators to
just download the "titles + abstract" feed. Several people in our space have
indicated that they read the abstract, and if they find it interesting, they
go to the web site itself rather than using the full content their
aggregator has brought them.
 
>  While I am a purist, I agree that inclusion of the
> <title> (and possibly <summary>) have value in the feed, particularly as
> a temporary display "holding space" while the reader fetches the
> separate entry document.

Progressive download (like IMAP's, I think) is a use-case I haven't thought
of, but it certainly looks promising.

Cheers,

Ziv Caspi
  cell: +972-53-668-751
    web: http://radio.weblogs.com/0106548/