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 s (as re
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 s
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 fro
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-01 18:45]:
> perhaps we need to explain the concept of 'entries' (as
> resources), as distinct from s (as representations), and
> explain that 'entries' must have unique IDs, and that the
> element of any ties it back to the
> 'entry' resource.
That de
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 s (as representations), and explain tha
* 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
On 30 Apr 2005, at 9:34 pm, Robert Sayre 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 desktop RSS aggregator would consider
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 w
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 determi
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
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 proba
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 prob
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 s
13 matches
Mail list logo
