RE: property value clarification

Jim Whitehead wrote:
"My recommendation is to leave this issue unresolved, 
and be silent on this topic within the spec."

I agree with Jim Whitehead that deeper discussion 
of the DAV property model should wait for the next 
round.

Jim Davis wrote:
"I concur, with one exception, namely the xml:lang attribute.  This
attribute must be recorded in order to provide international support.
Otherwise there is no way to do correct equality comparisons on properties."

I also agree with Jim Davis that the server should 
process the xml:lang attribute correctly so that DASL 
can do queries, etc. . However, that is a separate 
discussion from XML attributes "being part of the 
property value". 

The following is what I believe is necessary for correct 
processing of the xml:lang attribute:
(1) Most (but perhaps not all) servers will always
store a particular string property in one character set 
and one language. Many servers will store *all* string
properties in the same character set and language.
That implies that, in general, servers need to be free 
to translate string constants to whatever they need 
to store the value.
(2) Clients need to be able to indicate the language
and character set of string constants in their 
queries. The server knows the character set and
language of the stored values. The server can thus, 
in principal, perform the translations that are 
required and use the appropriate collation sequences 
in order to do the query comparisons properly.
(3) When a client gets a string back from the server, 
the server must be free to return it the way the
server chose to store it. If the server always returned
an arbitrary character set and/or language
for a string property depending upon the last
call on PROPPATCH, that would be equivalent to
requiring dynamic typing. IMHO DAV does not and 
must not require dynamic typing, but DAV can allow it.
(4) I don't believe that there is or should be a
requirement to get back the exact literal characters 
of a DAV property, let alone some XML attributes as well. 
(a) Given the whitespace handling rules of XML, that is
already unlikely. Whether XML whitespace is part of the
value or not is an issue when a property is stored.
Should DAV require discarded XML whitespace from
PROPPATCH to be returned for numeric, string, and 
datetime properties? It is a better design if the 
server doesn't bother to remember the discarded XML 
whitespace. (b) Most servers are going to store 
numbers and datetimes in binary form. So when you 
get a number or datetime back, it might have a
mathematically equivalent value, but the exact 
characters in the response might be different. That 
ought to be good enough.
(c) Since we never had the invariant condition
to get back the exact characters of the value, 
we haven't lost anything.

So I think we can be silent on whether or not XML 
attributes are considered part of the value
without causing DASL query problems.

Alan Babich

Received on Friday, 30 October 1998 15:44:59 UTC