Tim Bray wrote:
+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
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
