Seairth Jacobs said: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. The current <modified> element has additional semantics that should not be expected for the purposes it's used in SSFF. For instance, since <modified> is a timestamp, it can be used to sorting, but that is not the purpose of the value in this context. Using the value of <modified> as an opaque string in @etag is fine as long as people do not expect to treat the value as a timestamp. The same would be true if using a version-specific URL as the opaque string (people should not expect to treat it as a URL).
| <feed>
| <entry etag="etag_value">
| <link>entry_document_uri</link>
| <id>guid of entry document</link>
| </entry>
| </feed>
| | where @etag is optional.
Three comments:
1. Replace the use of @etag with that of <modified> which we already have.
2. <link> is already defined in Atom to be a URL that points to someI think that the <link rel=""/> format makes the most sense, at least given the current conversations going on.
human-readable representation of the entry. We'll need a new element type
(<linkToEntry>, <fullElement>, whatever) that would be defined to mean a URL
to a full entry in the Atom XML serialization format.
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?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.
Thus, an Atom feed resourceThis 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. 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.
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.