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 explains what the "content" of an element is. This is > perhaps a bigger problem.
Depends how deeply we want to naval gaze. The normative Infoset term would be "children", but that includes lots of things we don't care about. For example, text constructs with a type attribute of "xhtml" are supposed to a single div as their content. An XML handler listening closely would notice whitespace characters before and after the divs in the examples. It's my belief that the "character-by-character" comparison mentioned in the atom:id section could reference section "6.2.1. Simple String Comparison" in RFC3986. In fact, it's a MUST-level requirement of RFC3987 that they be compared that way. Of course, these comparisons are based on having a URI/IRI to begin with, and URI/IRIs don't begin with whitespace. 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 the weeds. That said, I certainly wouldn't object to any text warning people not to do it, or explicitly mentioning that you have to call the equivalent of String.trim(). Robert Sayre
