Subject: PaceExplainDuplicateIds

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 16:02:03 -0400

Feel free to suggest alternate mealy-mouthed wording. :)

== Abstract ==

Weakens the constraint on duplicate entry ids in feeds to a SHOULD.

== Status ==

Open

== Rationale ==

The proposed compromise to allow duplicate IDs in feeds, on the
condition that a source element is present, doesn't address the
problem of quick scripts that probably won't group duplicate IDs. This
means that compliant processors will still differ from one-off hacks.
Rather than legislate the constraint, we should explain the situation,
and give the validator a SHOULD-level requirement so a warning can be
triggered.

== Proposal ==

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.
}}}

== Impacts ==

== Notes ==

----

CategoryProposals

---

From: Antone Roundy <[email-masked]>
Date: Sat, 30 Apr 2005 14:17:27 -0600

On Saturday, April 30, 2005, at 02:02  PM, Robert Sayre wrote:

> problem of quick scripts that probably won't group duplicate IDs.

I don't understand the last part of this sentence--could you explain?

Thanks.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 16:34:06 -0400

> I don't understand the last part of this sentence--could you explain?

Sure. Take a look at the discussion here:
http://www.intertwingly.net/blog/2005/04/09/Clone-Wars

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.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sat, 30 Apr 2005 21:47:32 -0400

> different results than a well-written desktop aggregator.

There can be no expectation about interoperability of invalid feeds.  In 
the feed mentioned there, I presume that the "spid" part of the URI was 
meant to be substituted with some sort of product id.  The ids encoded 
inside the links clearly would do.  Heck, the links themselves are 
better "globally unique identifiers" than the ones provided as the guids.

One of the clearest requirements that aggregator authors have provided 
to Atom is the wisdom of requiring unique IDs on entries.  There may be 
consensus that unique by source is sufficient.

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 30 Apr 2005 23:15:40 -0400

Robert Sayre wrote:
> compliant processors will still differ from one-off hacks.
	Why in the world are we letting "one-off hacks" influence the design
of Atom? That strikes me as rather unwise. We aren't here to make life easy
for script-kiddies. We're here to design a format that allows us to build
useful applications for the people who rely on our systems. The fact that it
might be a little difficult for some children or hackers to build decent
code is not something that should enter into our considerations.
	The spec should STRONGLY state that each entry must have a unique
atom id. The point of the "require source" language is not to remove the
requirement for uniqueness but rather to provide a more useful way of doing
cross-feed determination of uniqueness.

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 23:21:45 -0400

> cross-feed determination of uniqueness.

OK, that's fine with me. There is no "required source" language,
though. Someone should write a Pace.

This WG has, shall we say, more active management than most. I'm
afraid I can't just write down what I think you mean.

Robert Sayre