Re: PaceExplainDuplicateIds
On 1/5/05 6:34 AM, Robert Sayre [EMAIL PROTECTED] 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.
Re: PaceExplainDuplicateIds
* Robert Sayre [EMAIL PROTECTED] [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
Re: PaceExplainDuplicateIds
On 2/5/05 1:51 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (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.
Re: PaceExplainDuplicateIds
* Eric Scheid [EMAIL PROTECTED] [2005-05-01 18:45]: perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (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
Re: PaceExplainDuplicateIds
On 1 May 2005, at 18:18, Eric Scheid wrote: On 2/5/05 1:51 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (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. Exactly. I think this will help dissolve the issue very easily. The way I am currently thinking of this is as follows. The entry/entry xml we find in a atom feed is a time stamped representation of a resource. It is the state of a resource at a particular time. Or perhaps better: it is metadata about the state of a resource at a particular time. If we then think of the entry id as a resource, then we may think of all of these xml representations as representations of that id, where the representations each specify the date and time of their validity. Because the representations contain the date and time of their validity they can be placed in a collection without ambiguity. So there is a little distinction we need to be careful of: an entry.../entry representation is a representation *of* the id resource, but these representations are *about* the state of some other resources at a particular time (most notably the link alternate resource). Henry Story http://bblfish.net/blog/ e.
Re: PaceExplainDuplicateIds
John Panzer wrote: Eric Scheid wrote: On 2/5/05 1:51 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (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. +1. 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
Re: PaceExplainDuplicateIds
On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: 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. I don't understand the last part of this sentence--could you explain? Thanks.
Re: PaceExplainDuplicateIds
Robert Sayre wrote: On 4/30/05, Antone Roundy [EMAIL PROTECTED] wrote: On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: 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. 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. 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
RE: PaceExplainDuplicateIds
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
Re: PaceExplainDuplicateIds
On 4/30/05, Bob Wyman [EMAIL PROTECTED] wrote: 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. 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
