Subject: Identifiers again

From: Graham <[email-masked]>
Date: Fri, 25 Mar 2005 17:47:18 +0000

1. Why are these two statements in the same paragraph?

    The content of an atom:id element MUST be created in a way that
    assures uniqueness; it is suggested that the atom:id element be
    stored along with the associated resource.

Storage assures persistence but does nothing to improve uniqueness. I'd 
recommend that the second statement be moved to the end of the 
paragraph before, and the remaining statement be found a home 
elsewhere.

2. This would leave room to discuss uniqueness in more depth, which 
currently isn't discussed. Is it acceptable to have a feed and entry 
use the same identifier? Does it imply some relationship? Is it 
acceptable to use a domain name I don't control (this would obj=viously 
threaten uniqueness), etc etc. Probably too late to get consensus on 
changes here, though, so I won't suggest any.

3. Regarding dereferencing:

    Though the IRI might use a dereferencable scheme, Atom Processors 
MUST NOT assume it
    can be dereferenced.

This is nice, but I'd prefer it to also say something like "Atom 
Processors MUST NOT make any assumptions about the relationship between 
the feed or entry and the dereferenced object". This is currently 
implied by the absence of any discussion, so I don't think it's a 
functional change.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Fri, 25 Mar 2005 18:41:00 -0500

Graham wrote:
> recommend that the second statement be moved to the end of the paragraph 
> before, and the remaining statement be found a home elsewhere.

That sentence is an oblique way of saying "don't use your 
auto-incrementing primary key or your title-based permalink to identify 
entries". Suggestions welcome.

> currently isn't discussed. Is it acceptable to have a feed and entry use 
> the same identifier? Does it imply some relationship? Is it acceptable 
> to use a domain name I don't control (this would obj=viously threaten 
> uniqueness), etc etc. Probably too late to get consensus on changes 
> here, though, so I won't suggest any.

I agree that it's too late. Those are hard questions.

> implied by the absence of any discussion, so I don't think it's a 

No matter how much we might wish it to be so, we can't outlaw that sort 
of thing.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 30 Mar 2005 01:07:43 +0100

>>    stored along with the associated resource.

persistence = ids must be the same each time the entry is generated
uniqueness = ids must be different from ids used for other entries

Storage helps with the former. Why are we implying it will help with 
the latter?

>> Processors MUST NOT make any assumptions about the relationship 
>> between the feed or entry and the dereferenced object". This is 
>> currently implied by the absence of any discussion, so I don't think 
>> it's a functional change.
>
> No matter how much we might wish it to be so, we can't outlaw that 
> sort of thing.

In case you've forgotten, WE ARE THE LAW. What a funny thing to say.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 29 Mar 2005 19:17:06 -0500

Graham wrote:
> Storage helps with the former. Why are we implying it will help with the 
> latter?

Hmm. Darn right. It's good advice, but it's not in the right place. Thanks.

Robert Sayre