Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-03-30 Thread Henry Story
I would just like to revisit this question, because it will help clarify the "alternate" relation. On 1 Mar 2005, at 11:39, Henry Story wrote: On 20 Feb 2005, at 13:25, Bill de hÓra wrote: Graham, Eric, My thinking goes like this, - Is there a difference between an entry and the chunk of XML you

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-03-01 Thread Eric Scheid
On 1/3/05 9:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote: > On 20 Feb 2005, at 13:25, Bill de hÓra wrote: >> Graham, Eric, > > Ok since the above chickened out of answering your questions above, > I'll do so myself. My apologies: I didn't see the second part of that email. I thought the exten

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-03-01 Thread Henry Story
On 20 Feb 2005, at 13:25, Bill de hÓra wrote: Graham, Eric, Ok since the above chickened out of answering your questions above, I'll do so myself. My thinking goes like this, - Is there a difference between an entry and the chunk of XML you see in a feed? The question is vague and open to many

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Henry Story
I like the way you put the question below. It is indeed very clear. But it does not seem incompatible with us adding some text now in the spec that acknowledges that we have not yet answered the questions you pose. I would surround this text with square brackets [] just as we have done with other

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Bill de hÓra
Henry Story wrote: Bill de hÓra then responded: [[ -1. That is of no little value to a user of the spec. Also, do read what I said earlier in this thread - I'm not looking to resolve ambiguity, I'm looking to specify what's going to be ambiguous. ]] To which I reply: This is getting to be a very

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Henry Story
On 23 Feb 2005, at 08:53, Henry Story wrote: On 23 Feb 2005, at 00:18, Bill de hÓra wrote: Sorry that should have been "Paul Hoffman wrote": My read of the mailing list is that people are simply looking at the model described in the document differently. Some folks actively want the model the wa

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Bill de hÓra
Henry Story wrote: I would be in favor of not resolving the ambiguity but of highlighting it with text such as [ whether more than one entry with the same id can appear in a feed document has not yet been resolved ] -1. That is of no little value to a user of the spec. Also, do read what I said

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Bill de hÓra
Henry Story wrote: On 23 Feb 2005, at 00:18, Bill de hÓra wrote: My read of the mailing list is that people are simply looking at the model described in the document differently. Some folks actively want the model the way the document currently reads, other actively want the model to be differen

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-23 Thread Henry Story
On 23 Feb 2005, at 00:18, Bill de hÓra wrote: My read of the mailing list is that people are simply looking at the model described in the document differently. Some folks actively want the model the way the document currently reads, other actively want the model to be different, and most don't c

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-22 Thread Bill de hÓra
Paul Hoffman wrote: At 12:25 PM + 2/20/05, Bill de hÓra wrote: Chairs/Editors, - I think that this discussion (repeat ids) is architecturally significant in terms of how Atom layers onto the Web and is best taken forward under feed state, - Feed state discussion ought to deal explicitly with

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-22 Thread Paul Hoffman
At 12:25 PM + 2/20/05, Bill de hÓra wrote: Chairs/Editors, - I think that this discussion (repeat ids) is architecturally significant in terms of how Atom layers onto the Web and is best taken forward under feed state, - Feed state discussion ought to deal explicitly with entry state, as th

Managing entries/entry state [was PaceRepeatIdInDocument solution]

2005-02-20 Thread Bill de hÓra
Chairs/Editors, - I think that this discussion (repeat ids) is architecturally significant in terms of how Atom layers onto the Web and is best taken forward under feed state, - Feed state discussion ought to deal explicitly with entry state, as that's the more difficult case. Graham wrote: