Simple Extensions and xml:base

2005-08-04 Thread David Powell
The intention of Simple Extension Elements is to provide a simple class of extension that is part of the Atom model, and can therefore be preserved end-to-end by implementions via publishing clients, servers, databases, and aggregators. We say that Simple Extension Elements are not language sens

Re: Comments Draft

2005-08-04 Thread Eric Scheid
On 5/8/05 3:07 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > src="http://www.example.com/atom"; /> how about this instead http://www.example.com/atom"; type="application/atom+xml" thread:idref="urn:foo:1" /> this way processors that have a basic understanding of wha

Re: Comments Draft

2005-08-04 Thread James M Snell
A. Pagaltzis wrote: * James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]: Personally, however, I think that the elegance and simplicity of in-reply-to and replies link rel values trumps defining them as elements in a separate namespace or an otherwise perfectly engineered solution. As for

Re: comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread James M Snell
A. Pagaltzis wrote: * Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 06:00]: ah, but how do you know those URIs are id's? or more specifically, is the following URI an id or a location? You don’t know. Just goes to show once again that Antone was right all along to rail against ab

Re: comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread James M Snell
Eric Scheid wrote: On 5/8/05 1:30 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: * Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]: What if those particular had @rel="in-reply-to", and per that spec would be the URIs. Would updating those URIs be wrong? If an atom:id happ

Re: Comments Draft

2005-08-04 Thread A. Pagaltzis
* James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]: > Personally, however, I think that the elegance and simplicity > of in-reply-to and replies link rel values trumps defining them > as elements in a separate namespace or an otherwise perfectly > engineered solution. As for specifying the sou

Re: comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread A. Pagaltzis
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 06:00]: > ah, but how do you know those URIs are id's? > > or more specifically, is the following URI an id or a location? > > You don’t know. Just goes to show once again that Antone was right all along to rail against abusing atom:link for th

Re: comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread Eric Scheid
On 5/8/05 1:30 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > * Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]: >> What if those particular had @rel="in-reply-to", and >> per that spec would be the URIs. Would updating those URIs >> be wrong? > > If an atom:id happened to be a dereferenca

Re: comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread A. Pagaltzis
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]: > What if those particular had @rel="in-reply-to", and > per that spec would be the URIs. Would updating those URIs > be wrong? If an atom:id happened to be a dereferencable HTTP URI and dereferencing produced 301, what would you do? The sa

comments spec: id URIs in @href, vs 301 Moved

2005-08-04 Thread Eric Scheid
A question... If I have a store of entries, which of course contain many s, and at some point I retrieve various of those links and find that some of them respond with 301 Moved and a new Location ... should I then be updating the s in my store? What if those particular had @rel="in-reply-to", a

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Robert Sayre
On 8/4/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > I believe that the term "content" is open to intelligent dispute. > Apparently the authors of RFC3470/BCP70 believe so too. Agree. > I won't dispute your read on the consensus of the working group Agree. > but I > would like to request that *SOM

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Sam Ruby
Bill de hÓra wrote: > 0. The validator isn't the spec. +1 to the sentiment that the validator isn't the spec. - Sam Ruby

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bill de hÓra
Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. The current normative text, "The element's content MUST be an > IRI", is clear and simple and supported by other well-understood > normative text, supported by lots of interoperable software, t

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bill de hÓra
0. The validator isn't the spec. cheers Bill James M Snell wrote: > > +++1 > > Joe Gregorio wrote: > >> On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote: >> >> >>> I don't really understand why this should be treated any differently >>> than the numerous other problematic things that could

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread A. Pagaltzis
* Tim Bray <[EMAIL PROTECTED]> [2005-08-04 20:25]: > I'm getting increasingly grumpy and "just fail" is looking > better and better. The way I read the conversation is that noone will dispute “just fail” if we do choose to adopt it. > I claim that text enjoyed strong, not rough, consensus suppo

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Sam Ruby
Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. The current normative text, "The element's content MUST be an > IRI", is clear and simple and supported by other well-understood > normative text, supported by lots of interoperable software, t

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread James M Snell
+++1 Joe Gregorio wrote: On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote: I don't really understand why this should be treated any differently than the numerous other problematic things that could happen if one doesn't take the spec literally. (I'd suggest spec prose trumps RNG grammar, a

Re: Comments Draft

2005-08-04 Thread James M Snell
I definitely appreciate all of the feedback on this. The conversation has definitely been helpful. Personally, however, I think that the elegance and simplicity of in-reply-to and replies link rel values trumps defining them as elements in a separate namespace or an otherwise perfectly engi

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Joe Gregorio
On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote: > I don't really understand why this should be treated any differently > than the numerous other problematic things that could happen if one > doesn't take the spec literally. (I'd suggest spec prose trumps RNG > grammar, as there's a lot of other

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Julian Reschke
Dave Pawson wrote: On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote: I'm getting increasingly grumpy and "just fail" is looking better and better. So for now, I'm -1 on an weakening or removing "The element's content MUST be an IRI" or analogous text in any other section. I'll stop

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Dave Pawson
On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. > So for now, I'm -1 on an weakening or removing "The element's content > MUST be an IRI" or analogous text in any other section. I'll stop > shouting if

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Dave Pawson
On Thu, 2005-08-04 at 17:45 +0200, Danny Ayers wrote: > > I don't want to allow whitespace. But this > > > > > > urn:foo > > > > > > is going to happen, is going to cause problems, and working around it > > does not strike me as being something you can foist entirely onto the > > spec's end

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Tim Bray
On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote: I propose trying harder, but I am open to "just fail". As am I. I am not OK with a long treatise on whitespace, like the one Tim suggested. If there is a MUST-breaking error in a feed, that's not an Atom document and I don't want to talk about

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread A. Pagaltzis
* James Aylett <[EMAIL PROTECTED]> [2005-08-04 15:25]: > On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote: > > > * Tim Bray wrote: > > >"Implementors are advised that there is a common class of > > >error in [...] > > > > Sorry but this is ridiculous; if we say X MUST Y even tho

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Danny Ayers
On 8/2/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > Graham wrote: > > From atompub-format-10, 4.2.6: "Its content MUST be an IRI" > > > > That to me is demonstrates a very clear intention of the working group > > that the content must be exactly equal to the IRI. My reading too. > I don't

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bjoern Hoehrmann
* Paul Hoffman wrote: >You can't compare an IRI with a non-IRI. So, if you are handed an >non-IRI (as in, an IRI-looking string that has whitespace around it), >should you fail immediately or try harder? I propose trying harder, >but I am open to "just fail". Well, if we expect that many conte

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Robert Sayre
On 8/4/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > I propose trying harder, but I am open to "just fail". As am I. I am not OK with a long treatise on whitespace, like the one Tim suggested. If there is a MUST-breaking error in a feed, that's not an Atom document and I don't want to talk about

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Paul Hoffman
At 2:42 PM +0200 8/4/05, Bjoern Hoehrmann wrote: * Tim Bray wrote: "Implementors are advised that there is a common class of error in [...] Sorry but this is ridiculous; if we say X MUST Y even though we know that many X won't Y we are abusing RFC 2119 terminology and make it much more diffic

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread James Aylett
On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote: > * Tim Bray wrote: > >"Implementors are advised that there is a common class of error in > >[...] > > Sorry but this is ridiculous; if we say X MUST Y even though we know > that many X won't Y we are abusing RFC 2119 terminolog

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bjoern Hoehrmann
* Tim Bray wrote: >"Implementors are advised that there is a common class of error in >[...] Sorry but this is ridiculous; if we say X MUST Y even though we know that many X won't Y we are abusing RFC 2119 terminology and make it much more difficult to evangelize 100% compliance, since this all

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bill de hÓra
Tim Bray wrote: > I'm strongly -1 on treating this as anything but an error. We may at > our discretion make it forgiveable. I really do not understand - it's an error or it's not not. Elsewhere in their replies, Paul and Robert seem to think this is obviously meaningful. Clearly I don't get

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Tim Bray
On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That works for me. Another idea is "Atom Processors MAY ignore leading and/or trai

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Paul Hoffman
At 11:43 AM +0100 8/4/05, Bill de hÓra wrote: Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That works for me. Another idea is "Atom Processors MAY ignore

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Robert Sayre
On 8/4/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > I don't understand the benefits of MAY. It sounds like this to me: > "whitespace is not allowed in certain elements, but you may ignore that > directive by trimming the content". What's the problem with that? That discourages sloppy feed genera

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bill de hÓra
Paul Hoffman wrote: > > At 7:37 PM -0400 8/2/05, Robert Sayre wrote: > >> One way of saying this would be "Atom Processors MAY ignore leading >> and trailing whitespace in _." > > > That works for me. Another idea is "Atom Processors MAY ignore leading > and/or trailing whitespace

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Graham
On 4 Aug 2005, at 11:25 am, Paul Hoffman wrote: That works for me. Another idea is "Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and ." This doesn't describe an interoper

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Paul Hoffman
At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That works for me. Another idea is "Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not all

Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Bill de hÓra
Sam Ruby wrote: > A note that Atom processors may consider leading and trailing space as > significant in attribute and element values would be enough to alert > people to the interoperability issues. But it wouldn't cater for them. That note would need to be a MUST to be effective. > Disallowi