Subject: Re: PaceEntryIdRequired

From: Eric Scheid <[email-masked]>
Date: Thu, 15 Jul 2004 00:43:59 +1000

> The "atom:id" element's content conveys a permanent, globally unique
> identifier for the entry. It MUST NOT change over time, even if other
> representations of the entry (such as a web representation pointed to by the
> entry's atom:link element) are relocated.
> 
ok so far...

> If the same entry is syndicated in two atom:feeds published by the same
> entity, the entry's atom:id MUST be the same in both feeds. atom:entry MUST
> contain an atom:id element, but MUST NOT contain more than one. The content of
> this element, when present, MUST be a URI.
> 

(1) clarification please: if the same entry is syndicated in other
atom:feeds published by NOT the same entity ... does the atom:id remain the
same? I would hope so ... can we reword to this?

    If the same entry is syndicated in more than one atom:feed
    the entry's atom:id MUST be the same in all those atom:feeds.

(2) editorial: strike "when present" from last sentence, since it will
always be present since it is now required ;-)

(3) detour: would it be better if <id> was instead @id on <entry>?

e.

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 12:07:03 -0700

> (3) detour: would it be better if <id> was instead @id on <entry>?

+1 on all three suggestions, but #3 may be worthy of some more debate. 
-Tim

---

From: Norman Walsh <[email-masked]>
Date: Thu, 15 Jul 2004 17:24:19 -0400

/ Tim Bray <[email-masked]> was heard to say:
|> (3) detour: would it be better if <id> was instead @id on <entry>?
|
| +1 on all three suggestions, but #3 may be worthy of some more debate.

In particular, if we call it "id" people will think it's an XML ID and
we don't mean that, we mean a URI. Less confusing, I think, to make
it an element.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The effects of weakness are
http://nwalsh.com/            | inconceivable, and more prodigious than
                              | those of the most violent
                              | passions.--Cardinal De Retz

---

From: "Andreas Sewe" <[email-masked]>
Date: Thu, 15 Jul 2004 23:44:26 +0200

> +1 on all three suggestions, but #3 may be worthy of some more debate.

Well, in my opinion URIs traditionally belong into attributes (especially
since there is no risk that the content model will ever include elements :-).
But a name of @id is also traditionally used for attributes of type xsd:ID,
not for those of type xsd:anyURI.

This being said I'm in principle in favour of #3, although the name of the
attribute should better be changed to something like @identifier to avoid any
confusion regarding its type.

Regards,

Andreas Sewe

---

From: Antone Roundy <[email-masked]>
Date: Thu, 15 Jul 2004 16:23:44 -0600

> confusion regarding its type.

Perhaps @uid?  (But not @guid!)

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 16 Jul 2004 02:04:26 +0100

> we don't mean that, we mean a URI. Less confusing, I think, to make

The goal of anything to do with URI naming must surely be to attain 
increasingly higher levels of confusion.

I nominate '@reference', as there's no 'de' in it.

cheers
Bill

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 16 Jul 2004 09:38:47 +0200

> +1 on all three suggestions, but #3 may be worthy of some more debate.

Yes, putting a non-XML ID into an @id attribute would not be a good idea,  
imho. When discussing this in the beginning, @id was dropped because an  
Atom ID couldn't fit the syntactical constraints of an XML ID. An URI is  
not a valid XML ID, and thus should the ID not look like on either.  
Another attribute is fine, though.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 00:02:07 +1000

> Another attribute is fine, though.

+1