On 20 Feb 2005, at 17:10, Graham wrote:
On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same atom:id.
Which part of "universally unique" didn't you understand?
Ok, I see so you interpret the "universally unique" in
[[
An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content MUST be a URI, as defined by [RFC3986]. Note that the definition of "URI" excludes relative references.
]]
to mean that there can only be one entry in a feed with the same id, and presumably across all feeds, or else why use the word "universally" and not "feedally"?
Why could we not then allow another id construct, call it "entryId" that would be what all entries that are just editorial changes of one another have in common?
This would be something like:
<feed>
...
<entry>
<id>tag:bblfish.net/entry1/version1</id>
<entryid>tag:bblfish.net/entry1/</entryid>
<title>Atom Robots Run Amok</title>
...
</entry>
<entry>
<id>tag:bblfish.net/entry1/version2</id>
<entryid>tag:bblfish.net/entry1/</entryid>
<title>Atom-Powered Robots Run Amok</title>
...
</entry>
</feed>As you can see in the above feed there are no two entries with the same id. Yet there are two entries with the same "entryid".
Would the above be an ok feed for you, or are there some other reasons why a entryid node would be illegal?
It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of aggregated feeds.
Aggregated feed generators are supposed to maintain atom:id unchanged when
they copy entries into an aggregate feed.
This is a fair point. I concede that multiple versions of entries with the same id is acceptable if and only if they have different feed ids in their head-in-entry, since essentially then they aren't in the same feed.
So should we replace "universally unique" above with "unique in a feed" then?
Graham
