I was not able to go and do the exercise I wanted to do, so here is a more carefully worded version ------------------------------------------------------------------------

The id construct in atom is ambiguous between two meanings. Since the
two meanings are orthogonal and not incompatible when properly distinguished,
the best solution is to distinguish them and allow both.


I would replace the following text in the spec:

------------
4.5�The "atom:id" Element

The "atom:id" element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed.
------------


with

------------

4.5�The "atom:versionId" Element

The "atom:versionId" element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed version. There can only be
one entry with the same versionId per feed document. There can be only one feed
document with the same versionId.


4.6�The "atom:id" Element

The "atom:entryId" element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. There can be more
than one entry per feed document with the same id. And there can be multiple
feed documents with the same id.


------------

Note:
atom:versionId is what I have called elsewhere the equivalence id relation
atom:entryId is what I have called the functional id relation



The above will allow the feed format to also be used as an archive format
if needed.


It clearly distinguishes the two types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate one
way and other Paces tried to disambiguate the other way.


As such it correctly resolves an ambiguity by allowing both options.

Henry Story

Ps. text above written quickly cause I have to go do some exercise.




Reply via email to