Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis

Lisa Dusseault wrote:
> 
> There are some language changes proposed by Julian that I'm OK with,  
> but it's clear we're thinking a little differently about whitespace --  
> read down a bit for that discussion and questions for client and server  
> implementors.
> 
> ...
 >
>> 2. I don't understand the part about non-significant whitespace. Why  
>> was it introduced, and what issue does that resolve????
> 
> First assumption: that there is non-significant whitespace, based on  
> reading the XML recommendation
> 
> For example, if my property name value in PROPPATCH request is
> 
>     <D:myprop xmlns:D="DAV:">
>         <myvalue xmlns="http://example.org/schema">
>             <stuff/><morestuff/>
>         </myvalue>
>     </D:myprop>
> 
> Then in this case, I believe all line returns and tabs introduced here  
> are non-significant.

But they are. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.4.4.p.7>:

"The XML attribute xml:space MUST NOT be used to change white space 
handling. White space in property values is significant."

> Second assumption:  that a server might strip non-significant  
> whitespace either at the beginning or end of the property value if it's  
> a XML value.  So a server could return in a PROPFIND response:
> 
> 
>     <D:myprop xmlns:D="DAV:"><myvalue xmlns="http://example.org/schema">
>             <stuff/><morestuff/>
>         </myvalue></D:myprop>
> 
> (Conversely, a server could *add* whitespace in the locations I just  
> removed whitespace.)

That would be a bug according to the current draft.

> Third assumption/evaluation: that a server might reasonably strip  
> non-significant whitespace in the *middle* of an XML property value.   
> So a server could also return
> 
> 
>     <D:myprop xmlns:D="DAV:"><myvalue  
> xmlns="http://example.org/schema"><stuff/><morestuff/></myvalue></D: 
> myprop>
> 
> (if this line wraps in your email reader, it was intended to be a  
> single line with no returns)
> 
> Why might a server do this?  If XML property values were stored as XML  
> trees for fast searching and processing, then the text representation  
> of the value could be reconstructed easily if whitespace did not need  
> to be preserved exactly as is.
> 
> If these assumptions are wrong or there's consensus that whitespace  
> rewriting is unreasonable, then I'd have to rewrite this text.

Actually what I'm asking for is that we don't change the text unless 
there clearly is a consensus to do so. The current spec says whitespace 
is significant, and as far as I can tell, nobody has asked for a change 
of that.

> ...

Best regards, Julian

Received on Thursday, 13 October 2005 19:07:28 UTC