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 accurately, you should trim the space yourself. > > Ecch. Blecch. Barf.
I think we all feel that way. > I suppose. That way too. > I personally think the framework of specifications is crystal-clear, > and per the letter of the law > > <atom:id> > http://example.com/foo > </atom:id> > > is totally illegal because the string \nhttp://example.com/foo\n does > not conform to the productions for either URI or IRI. As Graham noted, the issue is that differing persons approach this with differing notions of what the term "content" means in this context. "Document" and "Data" people approach these things with different filters. 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): <atom:id>http://example.com/foo</atom:id> Infoset views the below two examples as different: <atom:id><![CDATA[http://example.com/foo]]></atom:id> <atom:id>http://example.com/foo</atom:id> RelaxNG views all of the above as the same. > I am less convinced that people are actually going to do this, but I do > agree that if a substantial number *do* do this, implementors will > simply ignore us and code around it. So if the WG really thinks this > is a sensible clarification I won't scream too much. -Tim The reason that one line of code exists in the feedvalidator is because somebody did do it, existing feed readers supported it, and I couldn't defend the statement that the RSS 2.0 spec unambiguously prohibited it. 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. Disallowing leading and trailing whitespace in IRI references (including the isegment-nz-nc production), MIME media types, language tags, lengths, addr-spec, and date-time productions would lead to improved interoperability. I'm fine with either. - Sam Ruby
