Sorry for replying to my own posts. This problem is a little tricky.
Another way of looking at the problem is that the proposed limitation
is the same as thinking of id as an entry version identifier. This
interpretation of the id had I thought been rejected by many in the past.
I think that resolving what the id construct is by fiat in favor of the functional id or the equivalence id interpretation of id, cannot be
portrayed as a correct representation of the desires of this group.
Since this group has been split either way the best way to solve the
issue clearly is to allow 2 ids:
- versionId: this is the equivalence relation id, and there can
only be one entry with the same id per document.
- entryId: this is the functional relation id, and there can be
more than one entry with the same id per document.This I think would clearly solve the problem by allowing each side of the debate to have their requirements fulfilled.
Henry Story
On 17 Feb 2005, at 20:31, Henry Story wrote:
I should emphasize that there are in fact deeper problems with trying to limit the number of entries with the same id to one per document. The notion of an id that this entails, which in another mail I have called the equivalence relation id, in fact makes the whole notion of feeds chained by "next" and "previous" links inconsistent.
This will create a really deep flaw in Atom.
Therefore I think the conclusion that the group has decided not only against PaceRepeatIdInDocument but furthermore for a restriction is a understandable but very dangerous conclusion to come to.
sincerely,
Henry Story
On 15 Feb 2005, at 20:38, Henry Story wrote:On 15 Feb 2005, at 20:12, Tim Bray wrote:PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate <atom:id> in an <atom:feed>.
Mhh. First off that pace does not speak about allowing more than one id per entry, but rather of allowing more than one entry with the same id in a feed
document.
Secondly clarifying the spec the way you are doing does not take into consideration the consequences of doing so. These consequences include
many other paces which have received many -1s for many reasons. But the main
consequence is that the spec will not be finished in time, as you will be opening
the debate of archive formats. Allowing this pace through, solves the archive
problem that is required by the Atom Charter.
I think there should be serious discussion of why this Pace is not thought
to be appropriate. I don't think there are ANY good arguments against it.
Henry Story
