Subject: Re: PaceExplainDuplicateIds

From: Eric Scheid <[email-masked]>
Date: Sun, 01 May 2005 21:14:45 +1000

On 1/5/05 6:34 AM, "Robert Sayre" <[email-masked]> wrote:

> Say someone writes a quick PHP script that doesn't keep any state and
> loops through the entries to display them on a web page. They'll have
> different results than a well-written desktop aggregator.

a well written aggregator may well also mimic the behaviour of that PHP
hack, opting to display all versions of the entry with the duplicate ID.
This would be correct behaviour for a feed of wiki-page history, for
example.

e.

---

From: Graham <[email-masked]>
Date: Sun, 1 May 2005 14:55:55 +0100

> different results than a well-written desktop aggregator.

A well-written desktop RSS aggregator would consider it a mistake on  
the publisher's part and display all entries in the feed rather than  
throwing away data. The current Atom policy of banning duplicate ids  
backs up this policy. If you want to come up with a different policy,  
that's fine, but this Pace changes us from having one to having none.

-1

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 1 May 2005 17:51:37 +0200

* Robert Sayre <[email-masked]> [2005-04-30 22:15]:
> Remove the bullet point that reads
> 
> {{{ atom:feed elements MUST NOT contain atom:entry elements
> with identical atom:id values. }}}
> 
> Add a paragraph after the list that reads
> 
> {{{
> Atom Processors use the atom:id element found in Atom entries
> to identify distinct entries. It is RECOMMENDED that each entry
> in an Atom Feed Document have a distinct atom:id value.
> }}}

-1

I would +1 allowing identical IDs if it was required that the
entries sharing an ID had different sources.

Regards,
-- 
Aristotle

---

From: Eric Scheid <[email-masked]>
Date: Mon, 02 May 2005 02:18:00 +1000

> entries sharing an ID had different sources.

perhaps we need to explain the concept of 'entries' (as resources), as
distinct from <entry>s (as representations), and explain that 'entries' must
have unique IDs, and that the <atom:id> element of any <atom:entry> ties it
back to the 'entry' resource. It would then follow that multiple <entry>
representations which happen to have the same <atom:id> value are just
different representations of the source 'entry', and possibly even different
instantiations in time.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 1 May 2005 20:14:17 +0200

* Eric Scheid <[email-masked]> [2005-05-01 18:45]:
> perhaps we need to explain the concept of 'entries' (as
> resources), as distinct from <entry>s (as representations), and
> explain that 'entries' must have unique IDs, and that the
> <atom:id> element of any <atom:entry> ties it back to the
> 'entry' resource.

That definitely sounds like a plan.

Regards,
-- 
Aristotle

---

From: [email-masked] (John Panzer)
Date: Sun, 01 May 2005 11:43:34 -0700

>different representations of the source 'entry', and possibly even different
+1.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 01 May 2005 18:11:13 -0400

>>different representations of the source 'entry', and possibly even different

To me, this sounds very much like the following Pace:

   http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument

If the current proposal is different, how so?

If not, have people reviewed the discussion that occurred when that 
particular proposal was brought before the working group?

- Sam Ruby