On 5 May 2005, at 5:02 am, Tim Bray wrote:
<feed><title>My Portfolio</title> .... <entry><title>MSFT</title> <updated>2005-05-03T10:00:00-05:00</updated> <content>Bid: 25.20 Ask: 25.50 Last: 25.20</content></item> </entry> <entry><title>MSFT</title> <updated>2005-05-03T11:00:00-05:00</updated> <content>Bid: 25.15 Ask: 25.25 Last: 25.20</content></item> </entry> <entry><title>MSFT</title> <updated>2005-05-03T12:00:00-05:00</updated> <content>Bid: 25.10 Ask: 25.15 Last: 25.10</content></item> </entry> </feed>
Tim, model this as a blog first. Is it: a) One entry that's being updated? b) Hourly new postings with the latest price?
See, I think it's b). Which under any sensible circumstance would count as new entries, and therefoe get new ids. You're trying to use atom:id as a category system here. Let's say I post a new picture of my cat every day. Should all my blog entries have the same id?
Technical problems:
The problem multiple ids is that we don't have a date element that provides a definitive answer to the question, "What is the current version?", which 99% of the time is all an aggregator needs. For example, what happens if I retract an update to an entry, and presumably roll back atom:updated? The new version stays? If so, the spec of atom:updated needs changing.
I see you have the constraint "Their atom:updated timestamps SHOULD be different, and processing software SHOULD regard entries with duplicate atom:id and atom:updated values as evidence of an error in the feed generation". Does this apply temporally as well as spatially? For example, if the content changes the second time I load something, but the atom:updated doesn't, is that an error?
Again, atom:updated falls short for this purpose.
Finally, at pubsub, what happens when they download an entry from one feed, then the user edits it, but doesn't modify atom:updated, then they download the new entry from a second feed associated with the site. Different content, identical atom:ids, identical atom:updated => Invalid feed. They're not in any better position than they were before. This doesn't even solve the problem it's meant to.
"If an Atom Feed Document contains multiple entries with the same atom:id, software MAY choose to display all of them or some subset of them"
What does this even mean, other than "atom:id is meaningless, ignore it"?
I looked around and failed to find how we claimed we were going to do that while still forbidding duplicates, but it's possible I missed that.
Duplicate ids is a constraint of the atom:feed element. Use a different top level element, atom:archive, for archives.
Graham
