Subject: when should two entries have the same id?

From: Robert Yates <[email-masked]>
Date: Wed, 07 Jun 2006 13:29:24 -0400

This relates to work that we are doing with the publishing protocol, but 
is syntax related.

In an implementation of APP a single entry can appear both in the APP 
collection and in any number of arbitrary feeds that the site 
subsequently offers.

These feeds / collections can be optimized differently depending on the 
client.  For example, an entry in the collection feed may have its 
content "out of lined" whereas the "same" entry rendered in a feed may 
have its content inlined.  There are other different optimizations that 
we are investigating, that cause the entry representation in various 
feeds / collections to be different, even though it has originated from 
the same source.

So are these representations in the different feeds / collections the 
same entry or different entries?  Should they have the same id? and if a 
feedreader comes across two entries with the same atom id, what, if 
anything, can it infer from that? is it only that they came from the 
same source?

Many Thanks,

Rob

---

From: Henry Story <[email-masked]>
Date: Wed, 7 Jun 2006 19:57:35 +0200

You can have two entries or feeds with the same id, as long as they  
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but  
having different sizes throughout your life. At any point in time you  
have all the same properties...

Henry

On 7 Jun 2006, at 19:29, Robert Yates wrote:

>
> This relates to work that we are doing with the publishing  
> protocol, but is syntax related.
>
> In an implementation of APP a single entry can appear both in the  
> APP collection and in any number of arbitrary feeds that the site  
> subsequently offers.
>
> These feeds / collections can be optimized differently depending on  
> the client.  For example, an entry in the collection feed may have  
> its content "out of lined" whereas the "same" entry rendered in a  
> feed may have its content inlined.  There are other different  
> optimizations that we are investigating, that cause the entry  
> representation in various feeds / collections to be different, even  
> though it has originated from the same source.
>
> So are these representations in the different feeds / collections  
> the same entry or different entries?  Should they have the same id?  
> and if a feedreader comes across two entries with the same atom id,  
> what, if anything, can it infer from that? is it only that they  
> came from the same source?
>
> Many Thanks,
>
> Rob

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 07 Jun 2006 19:07:50 +0100

> have all the same properties...
/me wonders how long before a wiki engine based on Atom :)

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 7 Jun 2006 20:30:30 +0200

> /me wonders how long before a wiki engine based on Atom :)

You mean <http://www.xml.com/pub/a/2004/04/14/atomwiki.html>? :)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Wed, 07 Jun 2006 11:40:59 -0700

Henry Story wrote:
> 
> You can have two entries or feeds with the same id, as long as they have
> different updated time stamps.

That's not quite accurate.  Two entries with the same atom:id may appear
within the same atom:feed only if they have different atom:updated
elements.  The spec is silent on whether or not two entries existing in
*separate documents* may have identical atom:id and atom:updated values.

Consider the case where my personal weblog publishes two Atom feeds.
One is a "full-content" feed that publishes content as XHTML.  The
second is a "partial-content" feed that strips the markup and publishes
content as plain text in the atom:summary while containing an
atom:content with a src attribute to the original XHTML.  They exist in
two separate Atom documents and both are based on the same underlying
blog post.  The atom:id and atom:updated values for each entry are
identical.

Another example.  I post an iCal file to an APP collection.  In the
collection feed, I see a "media link entry" that uses content/@src to
point to the iCal.  However, another feed that is used to provide a
summary of upcoming events has entries whose content element contains an
XHTML rendering of the iCal files.  Each entry in the summary feed
corresponds to exactly one entry in the APP collection; should they or
should they not use the same atom:id and atom:updated values?

- James

>> This relates to work that we are doing with the publishing protocol,
>> but is syntax related.
>>
>> the client.  For example, an entry in the collection feed may have its
>> have its content inlined.  There are other different optimizations
>> that we are investigating, that cause the entry representation in
>> various feeds / collections to be different, even though it has
>> originated from the same source.
>>
>> same entry or different entries?  Should they have the same id? and if
>> a feedreader comes across two entries with the same atom id, what, if

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 7 Jun 2006 20:48:29 +0200

> have all the same properties...

Er, you can have two entries or feeds with the same if *and* updated
time stamps, as long as –for entries– they do not appear in the same
Atom Feed Document (and even this constraint might be removed in a
later revision of the spec, if I recall some past discussions on this
list correctly).

What one need to remember is that atom:id is an identifier for the
resource throughout its life, and that this is needed because entries
might not always be atomically retrieved (otherwise, "permaLinks"
would been enough).

The atom:id is an identifier for the resource, not for the
representation, so you might very well have the same entry (with the
same atom:id) with inlined content in one feed and out-of-line content
in another (or any other variation).

The behavior of consumers when they meet those different Atom
representations of the same entry is left undefined in the spec, and I
personnaly have no opinion at all (as I have been given such feeds,
and a) I'm not subscribed to any aggregate feed and b) I don't
aggregate feeds I'm subscribed to, each one lives in its own "folder"
in Thunderbird)…

-- 
Thomas Broyer

---

From: Henry Story <[email-masked]>
Date: Wed, 7 Jun 2006 21:26:58 +0200

Yes, I know, the atom syntax doc does not make statements about what  
happens in different feeds. But that does not mean that we are not  
forced logically to a conclusion. There was a very in depth  
discussion of this by the way on the atom semantics [1] mail list  
this February.

I think the Atom Protocol is forcing the issue towards there being  
only one entry per update time stamp. When you publish an entry with  
an updated time stamp it is going to have to appear in a feed at some  
point. And that won't be possible unless you overwrite one or the  
other entries.

Also think of agregators. If you have the same entry with the same id  
but different content, which is it going to choose?

Henry

[1] http://groups.google.com/group/atom-owl/browse_frm/thread/ 
357e36c4ee9cd31b/

On 7 Jun 2006, at 20:40, James M Snell wrote:
>>> APP
>>> the

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 7 Jun 2006 23:37:16 +0200

2006/6/7, Robert Yates <[email-masked]>:
> Thomas Broyer wrote:
>
> > and that this is needed because entries
> I don't understand what you mean "atomically retrieved" and hence why
> permaLinks would not have been enough.

By "atomically retrieved", I mean that you don't necessary have an
Atom Entry Document for each entry in a feed (actually, many CMSes
don't currently provide Atom Entry Documents, the only Atom documents
they provide are one or two feeds).

As Atom goes beyond content management à la blogs, there are also use
cases where the is no "alternate" representation: the entry in the
feed is the only representation of the resource, there's no way to
identify it using an URI, other than explicitely associate one through
the atom:id element.

Finally, atom:id is different from a permaLink in the sens that it's
only an identifier that might not be dereferenceable (or, to be more
accurate, that might not return anything but an error when
dereferenced): it's not a link, it's an identifier, which has the form
of an IRI, just as XML Namespaces are identified by URIs.
The advantage of such a design choice is that you can move entries
(hence changing "permaLinks") without changing their identifier. This
is particularly useful when, for example, switching from TypePad to
Blogger, and then to WordPress.Com, and then to a self-hosted blogging
system, and then changing the blogging system (and changing feed and
entry URIs, even if it's not a Good Thing [1]).

A Good Practice for these identifiers –at least when you're an
individual– is to make them "tag" URIs [2]

[1] http://www.w3.org/Provider/Style/URI
[2] http://www.taguri.org/

-- 
Thomas Broyer

---

From: Elliotte Harold <[email-masked]>
Date: Thu, 08 Jun 2006 08:44:13 -0400

> *separate documents* may have identical atom:id and atom:updated values.

They're ids, not guids. Certainly I would expect that there'll be some 
accidental conflicts. For instance one site might number its posts 
post1, post2, post3,...; and a different, unrelated site might do the same.

-- 
Elliotte Rusty Harold  [email-masked]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

---

From: Henry Story <[email-masked]>
Date: Thu, 8 Jun 2006 15:07:27 +0200

On 8 Jun 2006, at 14:44, Elliotte Harold wrote:

> They're ids, not guids. Certainly I would expect that there'll be  
> some accidental conflicts. For instance one site might number its  
> posts post1, post2, post3,...; and a different, unrelated site  
> might do the same.

No, they are guids. The datatype for an id is a IRI, which is a  
generalisaiton of URI. IRIs are constructed in such a way that it  
should be easy to construct universally unique ones without ever  
having name clashes. If name clashes there are, this will either be  
due to incompetence or to malevolence.

Henry

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jun 2006 15:14:53 +0200

> post1, post2, post3,...; and a different, unrelated site might do the same.

Sorry? That would be a bug. They *are* supposed to be globally unique.

See: <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6>.

Best regards, Julian