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

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.

On Oct 12, 2005, at 6:21 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> That works for me, unless more feedback from implementors comes up  
>> quite different.
>> Based on Julian's rewriting plus the discussion so far, here's some  
>> proposed wording:
>> The value of a property appears inside the property name element. The  
>> value
>> can be any kind of well-formed XML content: element content, text or  
>> mixed
>> content. When the property value contains element or mixed content,
>> namespaces that are in scope for that part of the XML document apply  
>> within
>> the property value as well, and servers MUST preserve namespaces in  
>> server
>
> s/namespaces/namespace names/
Sure.

>
>> storage for retransmission later. The server MAY preserve namespace  
>> prefixes
>> and non-significant whitespace.
>
> 1. Of course it *may* preserve namespace prefixes. I think this needs  
> to be rephrased the other way around: clients MUST NOT rely on  
> prefixes being preserved since some servers won't do that.
I don't mind either way of wording this.

>
> 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.

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.)

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.

IMPLEMENTORS: Do any servers rewrite whitespace in or before or after  
property values?  Do any client implementors have assumptions either  
way about this?


>
>> For any values where specific prefix choices or whitespace matter  
>> (e.g. property
>> values containing XPath with prefixes), clients might need to force  
>> the server to
>> store the exact property value by encapsulating the value in a CDATA  
>> section.
>
> This is a bit misleading as it kind of suggests that this would allow  
> to  use mixed or element content while preserving prefixes, which is  
> not the case. Using CDATA will just result in the property value being  
> a plain string, not tags.
>
> Thus my preference still is to require servers to do the right thing.  
> If we don't, the warning needs to be rephrased for example like this:
>
> "Servers are not required to preserve namespace prefixes in property  
> content, hence clients should not rely on them being preserved.  If  
> preservation of prefixes is required (such as in XPath expressions),  
> then it should be considered to use a different format for the value,  
> such as plain text containing escaped XML)."

Sure, I can call it plain text.

Lisa

Received on Thursday, 13 October 2005 18:30:06 UTC