http://www.intertwingly.net/wiki/pie/PaceOriginalAttribute
On 5/3/05, Martin Duerst <[EMAIL PROTECTED]> wrote: > > I'm not really happy with this. I found Martin's comments (copied in full below) to be accurate. So, I thought I would try another approach. Comments, suggestions, and alterations are welcome. Robert Sayre == Abstract == Preserve the original ID elsewhere, and require republishers to mint new IDs for *their entries*. == Status == Open == Rationale == Duplicate entry ids in feeds are too easy to create unintentionally, and the legitimate uses can't be verified as updates unless they come from the originating feed. == Proposal == Add an 'original' attribute to atom:source and reword as follows: {{{ If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. 4.2.11.1 The 'original' Attribute Atom entries can be republished and altered by intermediaries, but Atom feeds MUST NOT contain duplicate atom:id values. The 'original' attribute contains the entry's initial atom:id value. atom:source elements MUST have an 'original' attribute. }}} == Impacts == == Notes == ---- CategoryProposals On 5/3/05, Martin Duerst <[EMAIL PROTECTED]> wrote: > > I'm not really happy with this. Conceptually, it seems to replace > an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs > (remember what they expand to), that doesn't make sense. > What guarantee do we have that two feeds will be different? > (yes, these days, we get feeds over http, but there are other > ways to get feeds, where things may not be that easy). > > If we don't have a solution for the malicious case, and we > think we need one, we should work on some security stuff. > > If we think that accidential ID duplication is a problem, > then let's look at how we can improve the explanation. > After that, there may still be an occasional accident, > but the spec should be worded to catch that, not to > provide a loophole. > > If we have to allow duplicate IDs, I'd rather prefer we > do it without all this feed/source/... stuff: I.e. if > you are an aggregator and can't manage to do duplicate > elimination, you can just delegate the problem to the > next place in the feeding chain. > > Regards, Martin.