Property Life/Death

A live property has many different possible manifestations. However from the
point of view of how to write standards around the concept, the key idea is
that the client expects certain specified behaviors on the part of the
server.

For dead properties the client expects that the server will faithfully
record and return whatever values have been submitted for the property. The
client also expects that the server will only accept values which are
compliant with the DAV Property/Message object model (see my previous post
on that subject for more information). In other words, for a dead property,
the client expects the server to act like a notepad.

In the case of a live property the client expects the server to take some
action above and beyond just being a notepad. The exact nature of the
expectations are irrelevant, only their existence matters.

The purpose of providing this guarantee is to help clients control the
ramifications of their actions. Imagine, for example, a property which
returns the current system date. That is, the client expects that when this
property is retrieved the server will ensure that its value is equal to the
system date at the time the property's value was written. The client expects
something beyond notepad behavior of the server, thus the property is live.
If the client copies the resource to a server which doesn't know about the
system date property then the property will be dead. That is, the
destination server will not uphold the expectation that the retrieved value
will equal the current system date. Rather the server will act like a
notepad, recording the value of the property when it was copied and not
changing it after that point. If a program the client is writing depends on
the system date property being live on the destination then the client would
propably prefer the copy fail if the property's liveness can not be
guaranteed. DAV provides the client a means to express that wish.

				Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Tuesday, July 21, 1998 9:47 PM
> To: w3c-dist-auth@w3.org
> Subject: The meaning of life and death
> 
> 
> In a discussion taking place on the DASL list, it's become 
> somewhat unclear
> to me how to interpret section 3.1, which says "A live 
> property has its
> syntax and semantics enforced by the server".  I don't have a 
> clear sense
> of what is meant by "enforce", and hence what it means to 
> have a life.  If
> someone could answer the questions below it would help those of use
> designing DASL.
> 
> 1. What is life?
> 
> Suppose a property is stored (on the server) in an SQL table 
> in a column
> whose datatype is integer.  When the server does the 
> PROPPATCH, it parses
> the string to get the integer.  Does this parsing (regardless 
> of how errors
> are handled) suffice to make the property live?  Even if errors are
> silently ignored?
> 
> Suppose a property is stored (on the server) as a compound 
> data structure,
> and expressed (on the wire) in XML as a set of marked up 
> elements.  If the
> server parses the XML to generate the data structure, is this 
> a live property?
> 
> If not, suppose further that the datastructure has some 
> optional elements,
> with default values.  If the server provides these when creating the
> datastructure, is it now live?
> 
> 2. What is enforcement?
>  
> Clearly, rejecting a PROPPATCH with 409 Conflict is one form 
> of enforcement. 
> But is this the only kind of enforcement?
> 
> Suppose, in the examples above, the server is designed so that if the
> parsing fails for any reason (e.g., the integer is malformed, 
> or the XML
> encoding is well-formed but not valid) it does not reject the 
> PROPPATCH,
> but instead simply neglects to change the value, or stores an 
> XML element
> indicating the failure. Is such behavior violation of the 
> specification, or
> does it simply consitute enforcement (albeit perhaps a poorly designed
> one), and hence make the property live?
> 
> 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.
> Even aside from access control, servers are surely allowed to 
> do Unicode
> canonicalization.  Or is this also an example of "enforcing" 
> semantics?
> 
> best regards
> 
> Jim
> 
> 
> 
> 
> 
> 
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301
>

Received on Wednesday, 22 July 1998 15:03:44 UTC