RE: space

Julian:

SEARH must take a position on spaces. It is a critical
issue for string literals. I agree that we're defining a 
protocol -- something processed by software. The readability 
of the protocol string is secondary. However, examples are
presented in specs., and there is some benefit to having
these examples be readable. For many elements, extra 
whitespace doesn't matter. So including whitespace for 
such elements is good idea to enhance the presentation
of the example in the spec. (but not on the wire). For 
string literals, however, whitespace is critical.

Upon reflection, I agree with you that SEARCH should say
that all characters, including all whitespace (i.e., spaces,
tabs, carriage returns, vertical form feeds, etc.) in string 
literals are part of the string literal. 

Simpler is better.

Alan Babich

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, March 01, 2002 3:08 AM
To: w3c-dist-auth@w3c.org; www-webdav-dasl@w3.org
Subject: xml:space


Hi.

The WebDAV SEARCH draft currently has an issue regarding treatment of
xml:space [1]: it says, that the basicsearch grammer should respect
xml:space="default" in a literal element, so that

	<prop>
		<foobar xml:space="default">
			xyz
		</foobar>
	</prop>

would really be equivalent to:

	<prop>
		<foobar>xyz</foobar>
	</prop>

That's compatible with XML, but it's not consistent with WebDAV (which
doesn't say anything about xml:space). The only benefit of xml:space for
WebDAV I'm aware of is that you could have indented "beautified" message
bodies and have the receiver care about whitespace removal. However, as both
WebDAV request and response bodies are generated/consumed by code (not human
readers), that's hardly important.

So my proposal would be:

1) In WebDAV, state that whitespace *is* significant,

2) Drop the feature in WebDAV SEARCH's DAV:literal.

Comments?



[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rf
c.issue.JW14>

Received on Friday, 1 March 2002 16:00:06 UTC