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.
I can agree with the "cannot be any expectation" part of this, given the general vagueness of specification around feed-level atom:id; however, I'd observe that "not required to use the same atom:id" due to lack of clarity is distinctly different from "thus should not use the same atom:id".
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.
I'm not necessarily following the logic. See above statements. A use case for the benefits of sharing an atom:id (being able to tell that all feed documents derive from the same source collection) has been stated, and I suspect was the motivation for the sample usage in RFC5005. If this benefit is perceived to exist in other contexts as well, why would it not be applicable as well?
Regarding the argument that "filtering" is somehow different, isn't pagination or archival just filtering of a different type, i.e. by sequential order and/or by time rather than by other attributes of the feed content?
I've not yet seen a strong argument for why making them different is beneficial or helpful or why making them the same is harmful, but maybe I'm just being missing something.
Finally, I want to be clear that in stating the our implementation, I wasn't try to impose a particular generalized interpretation on feed id usage. I was just sharing experience and rationale as an implementor to inform the discussion. YMMV.
Cheers!
-- Kyle
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.
See above. Stating that something doesn't have to be done a particular way is not equivalent to saying it should not.
> 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.
Again, I don't see this as an argument against having the same atom:id. It just informs that doing so isn't useful (but is not harmful) in that particular context.
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.
I think this particular aspect isn't open for debate, at least to me. It certainly seems significantly useful for the same feed retrieved repetitively from the same url to have a constant atom:id.
* 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