I thought of this while flying home from RDU last night. I haven't
caught up on the mail, so apologies in advance if it's been said
before.
I was thinking about what Dare said about his aggregator and the fact
that if it sees a "republished" entry with the same atom:id, it
continues to sort by the original date, not the new date. (I'm not
suggesting that Dare is alone or that he's wrong, it just happens to
be his message that got me thinking along these lines.)
It seems to me that we have conflicting ideas about what identity
means and that it might help to look directly at that issue, so here
goes.
One idea of identity is that entries have immutable identity. That is,
an atom:id identifies an atom:entry that cannot change. Publishing a
different atom:entry with the same atom:id is logically an error. In
this view, an aggregator that notices an atom:entry with the same
atom:id as one it's already seen can disregard it without another
thought. It's either exactly the same as the one that's already been
seen, or it has changes that are erroneous and it can recover from
this error by ignoring the new entry.
Another view of identity is that entries are snapshots of an
abstraction that has identity. That is, an atom:id identifies an
abstraction that might or might not change. Publishing a different
atom:entry with the same atom:id represents some sort of change in the
underlying abstraction that's being reflected in the Atom world by
posting a new atom:entry. In this view, an aggregator that notices an
atom:entry with the same atom:id as one it's already seen might choose
to merge them, or pick one, or pick the one with the most recent
atom:modified date, or do something to "harmonize" the two entries.
The only thing it would never do is present both the atom:entries to
the user as if they were two different entries.
Choosing the former view suggests that Tim's idea of "a permanent
status page" for a project (like GenX or my own sxpipe) is an abuse of
Atom unless the atom:id is changed everytime the status page is
updated.
Choosing the latter view suggests that Dare's aggregator (and other
aggregators built along the same lines) should be changed. Exactly
what they should do probably need more discussion.
I think I lean towards the latter view, but there's definitely
something appealing about the simplicity of the former view.
Be seeing you,
norm
--
Norman Walsh <ndw@xxxxxxxxxx> | On the other hand, you have different
http://nwalsh.com/ | fingers.
Attachment:
pgp00159.pgp
Description: PGP signature