Antone Roundy wrote:
Bill de hOra wrote:
But Bill, it's not two different feeds, it's two different views of
the same feed -- an archive view, and a "latest entries" (a.k.a.
"sliding window") view. Thus the shared atom:id IS "globally unique
on a per my feed basis", just not on a per feed DOCUMENT basis.
What breaks if they have two different ids?
Perhaps nothing "breaks", but it's just a little odd to have the same
entries originating from two different feeds.
I don't find that odd; whereas I might find the same entry originating
from two different authors odd.
I presume neither
document is going to use an atom:source element to show that they're not
the originator of the entries, so it looks like you have two feeds and
are erroneously using duplicate IDs for their entries.
If nothing breaks, how can it be an error?
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.
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.
cheers
Bill
