[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: atom:id, urn:issn, feed archiving, and uniqueness
Kyle Marvin wrote:
On Feb 11, 2008 8:32 PM, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx
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
on the id of the partial lists of a collection, or the pages of a
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".
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?
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
used in concert to represent a single feed) are better off using their
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
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.
Also, given that there is no requirement that the various physical
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
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
> a feed 'is'. It did for me; I have a hard time explaining how,
> 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
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
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
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
* If not, is there a standards-based means of tracking this
It would help if the authors of RFC 5005 or 5023 can clarify if
a reason why these specs do not deal with the issue of atom:id in
archive documents, and partial lists.
Nikunj Mehta | XML Feeds Architect | +1.650.506.0679
Oracle Database Development
100 Oracle Parkway, Redwood Shores, CA 94065