Kyle Marvin wrote:
On Feb 11, 2008 8:32 PM, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx <mailto:nikunj.mehta@xxxxxxxxxx>> wrote:Postel's rule at work here. I am cautioning Atom users in general to not carry an expectation on the atom:id. Since it is not in the spec, it is gratuitous to use the same atom:id. I would do it too, but not sure that a total stranger would be able to use it meaningfully.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 expectationthat 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?
I don't doubt the benefits. The question is - is there a way to create a
standard that requires such sharing of atom:id across feed views? The
converse is - if the sharing of atom:id cannot be standardized, then is
there much benefit in reusing the atom:id?
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?
No argument here - I say as much below
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.Its great the GData is benefiting from the specialized interpretation of the atom:id and I would like that to be the standard. Your experience is definitely beneficial to this discussion.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
-- Nikunj Mehta | XML Feeds Architect | +1.650.506.0679 Oracle Database Development 100 Oracle Parkway, Redwood Shores, CA 94065