Kyle Marvin wrote:
On Feb 11, 2008 8:32 PM, Nikunj Mehta <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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".
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.
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.
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.
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.
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
