Re: DeltaV Draft

   From: "Mark A. Hale" <mark.hale@interwoven.com>

   > I agree that a server that supports both workspaces and working
   > resources might reasonably make such an association, and a server is
   > certainly allowed to set a DAV:workspace property on a working
   > resource (since any resource can have a DAV:workspace property) but
   > what would a client do with this property value (i.e. what
   > interoperability would we get by highlighting this fact)?
   > We've already got a complex spec, so I try to leave out anything
   > that doesn't directly contribute to interoperability.

   Per our telecon, it was non-obvious to an implementer that the properties
   are inherited.

As Tim pointed out, its probably best to avoid the term "inherited"
here.  The protocol states what kind of resources have what kinds of
properties.  It states that any resource can have a DAV:workspace
property; therefore, since a working resource is a resource, a working
resource can have a DAV:workspace property.

   I feel that adding a sentence or two like the following:

       A server may set a DAV:workspace property when a new
       working resource is created.  The property is asserted
       by servers that utilize server-managed workspaces for
       resource management.

   is clear as to what the property is and when it is set in the
   context of the working resources creation.

I don't see that this statement by itself would lead to any
significant interoperability.  Although it hints at what this property
could be used for, it doesn't provide anything that an interoperable
client can count on for it to mean.

   I feel that a client
   usage discussion would actually make the Draft Specification harder
   to read.

I agree.  My request for a client usage scenario was for us to
understand what you wanted it for, not for insertion in the protocol.

   A client can use this property-value to its advantage for a number of
   reasons: it can initiate a single cleanup instruction to the server by
   asking for a workspace deletion, the client can decide to generate the next
   working resource in the same workspace in order to due synchronization in
   off-line editing, and others.

An interoperable client can't do any of these things unless the
protocol requires specific behavior that produces this result.  For
example, we could add a postcondition to the DELETE method that says
"whenever a workspace is deleted, all working resource that identify
that workspace in their DAV:workspace property MUST be deleted".

Perhaps that is the change you'd like to see in the protocol?
Assuming it is, do people agree that this is something that should be
in the protocol?  I'm a bit concerned about adding storage cleanup
semantics into the protocol, since this tends to be a very
implementation dependent area.

Cheers,
Geoff

Received on Tuesday, 16 January 2001 11:28:37 UTC