Bill de hOra wrote:
Antone Roundy wrote:
And by the way, is the archive document one monolithic document
containing everything, or is it going to be split into a chain of
archive documents? If it's a chain, surely you wouldn't give each
document in the chain it's own ID, right?
Why not?
The reason to use the same ID in both cases is to show that they both
represent the same feed -- that the one is the archive of the other.
Not that there is an explicitly worded statement, but one would consider
using the same ID in different archive documents of one feed. This is
how the example in section 4 of RFC 5005 illustrates archive documents.
In Antone's words, these form a chain of archive documents corresponding
to a large feed.
However, neither RFC 5005 nor RFC 5023 specifically state a requirement
on the id of the partial lists of a collection, or the pages of a feed.
In the absence of such a requirement, there cannot be any expectation
that they are all identified identically. Given this, it seems perfectly
logical to treat the id of a feed as a container aka feed document
identifier, and that different containers aka feed documents (even when
used in concert to represent a single feed) are better off using their
own identifiers.
Also, given that there is no requirement that the various physical views
of a feed -- pages, archives, subsets derived through queries, etc --
carry a single id, the atom:id element inside a feed loses any meaning
beyond a "container identifier". Applying this I conclude that there is
no requirement that the GData query feed have the same atom:id as the
one present in the collection feed.
Try running Atom over XMPP. I think it might change how you view what
a feed 'is'. It did for me; I have a hard time explaining how, but it
seems that feeds are a workaround for HTTP, which doesn't have
containers or iterators.
Bill seems to suggest that seen in the context of XMPP, a feed document
as a container is equivalent to a stream. Therefore, the stream
identifier, seen as the session key, does not have any permanence. Not
only that, there cannot be correlation between the identifiers of
different streams.
However, feeds are used for a one-to-many communication whereas XMPP
streams are used for one-to-one communication, IMHO. It helps to have
the same id be used for different feed documents, even those obtained at
different times from the same URL.
* Isn't this how feed aggregators seem to track the evolution of a
feed's contents over time and to present a historical view of that
feed?
* If not, is there a standards-based means of tracking this evolution?
It would help if the authors of RFC 5005 or 5023 can clarify if there is
a reason why these specs do not deal with the issue of atom:id in pages,
archive documents, and partial lists.
Nikunj
