RE: datatyping is not needed

After rereading section 3.1 of the WebDAV spec., I may
have improved my understanding, and I have a question.

(1) The WebDAV spec. says "The name of a property identifies the
property's syntax and semantics, ...". The domain
of values of the property captures much of its semantics.
A domain of values is a subset of a datatype. For example,
the "Age Of Person In Years" domain is subset of the datatype 
"Integer". Thus, I read this sentence as a property can have 
only one domain, and by implication only one datatype. (A 
property can NOT have the semantics of an Age Of Person In Years 
on resource A and the semantics of Author on resource B.)

(2) There are "live" and "dead" properties. I think I understand
live properties. For case (a), getcontentlength is a good
example. It's a readonly value maintained by the server.
For case (b), Age Of Person In Years is a good example. The 
server will reject a value with extraneous characters such as
letters, since the datatype of the domain is Integer. The
server knows how to order ages and test them for equality,
since they are integers.

(3) The dead properties give me pause: "A dead property has its
syntax and semantics enforced by the client; the server merely
records the value of the property verbatim." The way I
read this sentence, all the server can do is store the string 
embedded in the XML for PROPPATCH that was sent to it AS A STRING
(or null out the property, according to the "set" or "remove" tag). 
Since the server is not permitted to have any idea of the client's
semantics, the server can't in general do ordering properly. 
In fact, the server can not, in general, even test for equality 
properly. Thus, it would seem that dead properties 
aren't necessarily searchable or sortable in a useful way
(except as far as they are viewed as strings),
but they are selectable. For some subset of the 
dead properties, pattern matching, content based 
retrieval, and even equality and ordering may be useful. 
For other dead properties, none of those operations may be 
useful. In order for some of the string stuff to work 
properly, the collation sequence and the character 
repertoire must be known. There is no provision for 
making collation sequence or character repertoire 
explicit, so defaults will have to be used.

I guess the way to reconcile (1) and (3) is: A property
has exactly one set of "client" semantics; the "client"
semantics of live properties are known and enforced 
by the server and are, therefore, the same as the server
semantics; the "client" semantics of dead properties are 
unknown to the server and not enforced by the server, 
and the server semantics is that of strings. 
The clients define the "client" semantics of dead properties, 
and the semantics may or may not be those of strings, 
but there is still only one "client" semantics for a property.

The WebDAV spec. makes no distinction between famous
and obscure dead properties, or else I missed it (sorry).

Is this the distinction: The difference between famous
and obscure dead is simply whether the dead property is a key
of retrieval or not. A famous dead property is a key of 
retrieval (e.g., there is a B-tree for it). Obscure dead 
properties are not retrieval keys.
Either way, the server can search and sort the dead
properties as if they were strings. Being a key (or not)
only affects the performance of queries, not the semantics. 

If the clients rigorously follow sufficient encoding and 
formatting conventions for the dead properties, then string 
operations can thereby be made useful to the client in some 
cases. (For example, the client could pad integers out to a 
fixed length with leading zeroes to induce integer valued dead 
properties to collate the same as positive integers 
as Jim observed in his e-mail.)

Jim: Am I getting warm?

Alan Babich

Received on Tuesday, 21 July 1998 15:54:32 UTC