RE: The meaning of life and death

In the case of live properties it is up to the property's definition to
decide what transformations are allowed. So one could imagine having a
property which states that if you submit a number in scientific notation
then it MUST be returned in scientific notation. There is no general rule,
it is up to each live property to decide what its behavior is.

		Yaron

> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Wednesday, July 22, 1998 12:21 PM
> To: 'Jim Davis'; w3c-dist-auth@w3.org
> Subject: RE: The meaning of life and death
> 
> 
> > 1. What is life?
> 
> The spec. says (section 3.1): "A live property has its syntax
> and semantics enforced by the server. Live properties include
> cases where a) the value of a property is read-only, maintained
> by the server, and b) the value of the property is maintained
> by the client, but the server performs syntax checking on
> submitted values." This seems clear to me now.
> 
> For live (a) properties, getcontentlength is a perfect
> example. It is readonly, and is maintained by the server.
> The client doesn't have to make any effort to maintain
> the value -- the server maintains it automatically.
> 
> For live (b) properties, the notion of the domain of values 
> of the property is absolutely necessary: The DOMAIN OF VALUES 
> of a property is what largely captures its semantics 
> (examples: zip code, street address, house number, Title, etc.).
> Domains are subsets of values of some datatype. (For example,
> zip codes are a finite subset of the integers.)
> In order to enforce the SYNTAX of the string-ized 
> representation of the value in the protocol, the server 
> MUST know the DATATYPE. In order to enforce the SEMANTICS, 
> in general the server MUST know the DOMAIN. Structures
> are a denumerably infinite set of datatypes. Servers
> are free to have structures as values of properties,
> expressed as XML markup or any other way, with or without
> defaults for some fields, etc. There are no surprises for live (b).
> 
> What is death?
> 
> All dead properties must be strings that are stored by the server
> and returned VERBATIM. They logically can not be anything else,
> because the server is guaranteed to be ignorant of what concept
> the client has in mind for the datatype and domain,
> and the server must return the value verbatim. Dead properties 
> really weren't even worth calling special attention to, IMHO. 
> It would have been better to say that string property values 
> are stored and returned verbatim, but that's normally assumed
> anyway.
> 
> > 2. What is enforcement?
> >  
> > Clearly, rejecting a PROPPATCH with 409 Conflict is one form 
> > of enforcement. 
> Yes.
> > But is this the only kind of enforcement?
> The possibility of the server quietly not storing the value
> is a very poor design, IMHO, and I propose that we reject that 
> alternative by not implementing it.
> 
> > I don't see anyplace in the spec that says that the value 
> > returned by a
> > PROPFIND must be byte for byte identical with that deposited 
> > by PROPPATCH.
> 
> For dead properties, the spec. says that value MUST be returned
> VERBATIM. For live properties, the spec. is quiet. IMHO it
> is perfectly reasonable for the value returned for a live (b)
> property to be equivalent, based upon understanding of
> the datatype and domain of the property. For example, strings 
> would obviously have to come back exactly. But a floating point 
> number could come back in scientific notation (e.g., 1.31E+01)
> or fixed point notation (e.g., 13.1), and that would be 
> fine IMHO.
> 
> Alan Babich
>

Received on Wednesday, 22 July 1998 15:59:46 UTC