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

On Aug 4, 2005, at 21:55, Joe Gregorio wrote: "Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B." Thi

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

Using Sun's 'relames' [1] it is *nearly* possible to validate an instance as is intended by the text! Where (datetime for instance) an element content must not have whitespace, relames picks it up nicely. There must be no white space before or after a date time value

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

> -Original Message- > From: Tim Bray [mailto:[EMAIL PROTECTED] > Sent: Monday, August 08, 2005 1:58 AM > To: Sam Ruby > Cc: atom-syntax@imc.org > Subject: Re: spec bug: can we fix for draft-11? > > > > On Aug 4, 2005, at 1:04 PM, Sam Rub

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

Tim Bray wrote: > > On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: > >> 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

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

On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote: To an Infoset person, this following is a completely different stream from the example above (please ignore any line breaks that your email client may insert): http://exam ;ple.com/fooatom:id> I believe this is incorrect, see http://www.w3.org/TR/

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

On Aug 7, 2005, at 5:41 PM, Bill de hÓra wrote: Exclusive canonicalization (which is the one we care about here) like canonicalization keeps whitespace inside element content significant. Those bytes are counted. I take that as meaning in the dsig case, trimming is broken. The c14n/dsig imple

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

On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: 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, suppo

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

Brett Lindsley wrote: > I was just observing most of this discussion, but I am wondering how > much of an issue the whitespace issue will cause when generating > signatures. Obviously, different signatures will result when signing > an element that has white space and one that does not. Does the >

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

? Brett. - Original Message - From: Walter Underwood <[EMAIL PROTECTED]> Date: Friday, August 5, 2005 4:37 pm Subject: Re: spec bug: can we fix for draft-11? > > --On August 4, 2005 9:31:55 AM -0700 Tim Bray <[EMAIL PROTECTED]> > wrote:> > > So for now, I&#x

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

--On August 4, 2005 9:31:55 AM -0700 Tim Bray <[EMAIL PROTECTED]> wrote: > > 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 I'm in > a small minority here. -Tim Wow, this string has made my "

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

On 8/5/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > The siutation didn't just happen to be vague, we made it vague, I don't > agree it doesn't matter, and if the Atom spec can't get it's story > straight on whitespace to the extent one of the editors is going to > advise people to ignore a MUST d

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

A. Pagaltzis wrote: I suggest simply the following: in 4.2.6 (The "atom:id" Element), change Its content MUST be an IRI, as defined by [RFC3987]. to read: Its content MUST be an IRI, as defined by [RFC3987], and MUST NOT contain any whitespace. It doesn’t change anything, it jus

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

Robert Sayre wrote: > On 8/5/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > >>If you're going to recommend ignoring it in practice, why not recommend >>throwing it out? Why equivocate? > > > You keep saying "equivocate", as if there were some hard-to-swallow > truth I'm avoiding. I've said it

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

* Tim Bray <[EMAIL PROTECTED]> [2005-08-05 14:05]: > Uh, anyone who's lazily concatenating strings is pretty soon > going to end up with a free ampersand or something worse in > their Atom feed. Right? I think that’s a bit grand of a generalization. It’s not hard to build XML by concatening stri

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

On 8/5/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > If you're going to recommend ignoring it in practice, why not recommend > throwing it out? Why equivocate? You keep saying "equivocate", as if there were some hard-to-swallow truth I'm avoiding. I'm suggesting saying something vague because the

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

Tim Bray wrote: > > On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote: > >> Leading and trailing whitespace input for >> these fields should be discarded by a robust scanner, and doing so >> proposes no risk to compliant feeds, unlike guessing the "true >> meaning" of an ampersand in an RSS feed. S

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

On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote: Leading and trailing whitespace input for these fields should be discarded by a robust scanner, and doing so proposes no risk to compliant feeds, unlike guessing the "true meaning" of an ampersand in an RSS feed. So, it will be my recommendation t

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

Robert Sayre wrote: > I'll also note that this requirement has basically zero value for a > desktop aggragator. I have only written three or four Atom parsers, > but I think the approach that has the best mix of performance and > correctness is one where SAX events are treated as input events for

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

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?

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?

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?

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?

* 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?

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?

+++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: spec bug: can we fix for draft-11?

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?

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?

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?

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?

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?

* 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?

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?

* 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?

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?

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?

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?

* 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?

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?

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?

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?

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?

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?

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?

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?

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

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

On 02/08/2005, at 9:15 PM, Tim Bray wrote: So if the WG really thinks this is a sensible clarification I won't scream too much. It's probably necessary any way, because RFC3470/BCP70 Section 4.16 encourages specs to give guidelines about white space; Implementers might safely assume t

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

On 3 Aug 2005, at 2:04 pm, 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. +1 Graham

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

Tim Bray wrote: > > On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: > >> One way of saying this would be "Atom Processors MAY ignore leading >> and trailing whitespace in _." That is, no existing >> software is buggy, but if you want to be sure your document is >> processed accuratel

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

* Tim Bray <[EMAIL PROTECTED]> [2005-08-03 06:30]: > I personally think the framework of specifications is > crystal-clear, and per the letter of the law > > > http://example.com/foo > > > is totally illegal because the string > \nhttp://example.com/foo\n does not conform to the productions

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

On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That is, no existing software is buggy, but if you want to be sure your document is processed accurately, you should trim the space your

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

On 8/2/05, Graham <[EMAIL PROTECTED]> wrote: > On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote: > > > For me, the most disturbing aspect of this debate is that any > > resolution will provide very, very little interoperability gain. > > Agreed. All we need to do is decide one way or the other what

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

On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote: For me, the most disturbing aspect of this debate is that any resolution will provide very, very little interoperability gain. Agreed. All we need to do is decide one way or the other what the spec should say. That said, I certainly wouldn't

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

Robert Sayre wrote: > For me, the most disturbing aspect of this debate is that any > resolution will provide very, very little interoperability gain. URIs, > like XML Elements, cannot begin or end with whitespace. I don't > believe it's worth mentioning in the spec, and I think we're off in > th

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

On 8/2/05, Graham <[EMAIL PROTECTED]> wrote: > > On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote: > > > > As it stands now, the spec does NOT clearly outlaw leading and > > trailing > > whitespace from ids > > > > I've been trying to argue with this but I can't find a normative > reference that expl

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

On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote: As it stands now, the spec does NOT clearly outlaw leading and trailing whitespace from ids I've been trying to argue with this but I can't find a normative reference that explains what the "content" of an element is. This is perhaps a bigger

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

On Tue, 2005-08-02 at 19:11 +0200, Bjoern Hoehrmann wrote: > For RFCs see . Thanks. Just playing. With schema The example below parses well with James Clarks relax tools and the sun validator. http://www.example.com";> http://exam

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

* Dave Pawson wrote: >> > Even if we decide that whitespace is not significant, I do believe that >> > having the feedvalidator issue a warning in such cases is appropriate. >> >> +1 > >What is the IETF version of an errata sheet? Is that the right >place to tackle this? For RFCs see

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

On Tue, 2005-08-02 at 15:24 +0100, Bill de hÓra wrote: > Sam Ruby wrote: > > > Even if we decide that whitespace is not significant, I do believe that > > having the feedvalidator issue a warning in such cases is appropriate. > > +1 What is the IETF version of an errata sheet? Is that the right

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

A. Pagaltzis wrote: > > At the very least, the normalization procedure that the spec > RECOMMENDS should contain language about stripping surrounding > whitespace. I too would like to see that added to the recommended normalization rules in section 4.2.6. That would make my job easier if somebo

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

Sam Ruby wrote: > Even if we decide that whitespace is not significant, I do believe that > having the feedvalidator issue a warning in such cases is appropriate. +1 cheers Bill

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

* Sam Ruby <[EMAIL PROTECTED]> [2005-08-02 16:05]: > I'm not yet sure what the right thing to do here is, but lets > to do the right thing. The spec as defined already leans in the direction of favouring simplicity in consumers in many areas, but does so particularly heavily when it comes to IDs.

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

Sam Ruby wrote: ... Why would they be legal with the RNG grammar From : For all ·atomic· datatypes other than string (and types ·derived· by ·restriction· from it) the value of whiteSpace is collapse and cannot be changed by

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

Julian Reschke wrote: > > Robert Sayre wrote: > >> On 8/2/05, James Cerra <[EMAIL PROTECTED]> wrote: >> >>> Neither of those are strictly legal, since white space is illegal in >>> both IRI >>> and RFC 3339 (dates) I think. However they are legal with the Relax >>> NG grammer >>> used. >> >> Ye

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

On 8/2/05, Julian Reschke <[EMAIL PROTECTED]> wrote: > Me confused. > > (), > how exactly does this allow whitespace around the xsd:datetime value??? http://lists.xml.org/archives/xml-dev/200309/msg00434.html

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

* Sascha Carlin <[EMAIL PROTECTED]> [2005-08-02 13:10]: > Agreed. Why not do it? Instead of > > > some-uri > ... > > > it could read > > >... > I have always wondered why it wasn’t done this way. Another reason this would have been good is that it would have enabled addressing

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

Graham wrote: > > On 2 Aug 2005, at 12:50 pm, Ian Davis wrote: > >> The two examples that Bill gave WILL happen in the wild and Atom >> consumers will just deal with it by stripping the whitespace anyway >> despite what the spec says now. I think this should be endorsed in >> the spec for int

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

Robert Sayre wrote: On 8/2/05, James Cerra <[EMAIL PROTECTED]> wrote: Neither of those are strictly legal, since white space is illegal in both IRI and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer used. Yes, they are. Relax NG regex matching strips leading and

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

Julian Reschke wrote: > > James Cerra wrote: > >>> Ian Davis wrote: >>> Graham wrote: That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical

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

On 8/2/05, James Cerra <[EMAIL PROTECTED]> wrote: > Neither of those are strictly legal, since white space is illegal in both IRI > and RFC 3339 (dates) I think. However they are legal with the Relax NG > grammer > used. Yes, they are. Relax NG regex matching strips leading and trailing whites

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

James Cerra wrote: Ian Davis wrote: Graham wrote: That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down i

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

On 02/08/2005 14:11, Graham wrote: I (and probably others) have already put code out into the wild in the assumption there is no whitespace. As I said before, it's too late for a solution that changes the meaning of the spec. Does your code reject the content of atom:id if it doesn't confor

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

On 2 Aug 2005, at 12:50 pm, Ian Davis wrote: The two examples that Bill gave WILL happen in the wild and Atom consumers will just deal with it by stripping the whitespace anyway despite what the spec says now. I think this should be endorsed in the spec for interoperability. I (and proba

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

> Ian Davis wrote: > > Graham wrote: > > That to me is demonstrates a very clear intention of the working group > > that the content must be exactly equal to the IRI. Changing this to > > allow whitespace would represent a major technical change to the > > format. I will figuratively lie down in

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

Sascha Carlin wrote: >>[You capture the essence when you mention machine-readable content. >>Really, that stuff should go into attributes not element content for >>exactly these kinds of reasons.] > > > Agreed. Why not do it? I Probably because it trades a spec text fix for a design fix. Not t

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

On 02/08/2005 10:51, Graham wrote: > That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road i

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

Bill de hÓra wrote: Julian Reschke wrote: Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From a

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

> 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-users. [...] When we say MUST above, we need to be clear on how > we're su

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

Julian Reschke wrote: > > Graham wrote: > >> >> On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: >> >>> The design intent of character-by-character cmp as I understood was for >>> the URI contained by the element. I think confusing the element content >>> with the URI is a spec bug. >> >> >> >>

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

Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: "Its content MUST be a

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

Sascha Carlin wrote: > Graham said: > >>the format. I will figuratively lie down in the road if anyone >>suggests whitespace should be allowed around any machine-read content >>(uris, @type, @rel, etc). > > > +1. Possible whitespace would add general check & removal calls to any > processor. Wh

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

Graham wrote: > > On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: > >> The design intent of character-by-character cmp as I understood was for >> the URI contained by the element. I think confusing the element content >> with the URI is a spec bug. > > > From atompub-format-10, 4.2.6: "Its c

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

Graham said: > the format. I will figuratively lie down in the road if anyone > suggests whitespace should be allowed around any machine-read content > (uris, @type, @rel, etc). +1. Possible whitespace would add general check & removal calls to any processor. When you process 100 items, thats not

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

On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: "Its content MUST be an IRI" That to