Subject: PaceOriginalAttribute

From: Tim Bray <[email-masked]>
Date: Thu, 05 May 2005 15:42:28 -0700

+1

I'm not 100% convinced it solves the problems Rob says it does, but it 
seems cheap, lightweight, and unlikely to cause any harm. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Fri, 06 May 2005 16:53:12 -0400

> seems cheap, lightweight, and unlikely to cause any harm. -Tim

I'm growing increasingly comfortable with the concept of allowing 
redistributors to assign new ids as long as they track the original 
(i.e.: not immediate predecessor!) entry.

That being said, I have two things I want to think more about w.r.t. how 
this Pace is currently worded.  (Note: the first is actually only a nit 
concerning the current draft, not the Pace itself):

1) "MAY be preserved"

    I would prefer if this were recast not so much as an RFC 2119
    interoperability statement, but rather as a definitional one.
    "original attributes in atom:source elements are used to
    indicate..."  Something along those lines.

2) "Atom feeds MUST NOT contain duplicate atom:id values"

    How did that get in there?  Depending on how you read it, this Pace
    is incompatible with PaceAllowDuplicateIDs, implying that Tim's
    +1 above can be construed as voting against a Pace he authored!

Whether or not the work group comes to consensus about allowing multiple 
entries to share the same ID in a feed, it still is true that entries 
may change over time.  Perhaps atom:source elements could also define an 
@updated attribute.  As atom:updated is a required element for 
atom:entry, it would not be an unreasonable burden to require @updated 
attributes on atom:source elements.

- Sam Ruby

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 11 May 2005 00:39:31 +0200

> seems cheap, lightweight, and unlikely to cause any harm. -Tim

+0.8

It seems to me the proposed wording doesn't accurately reflect the 
rationale...

-- 
Thomas Broyer