Re: DeltaV Draft

OK, I (finally :-) get it.

The section on working resource properties should enumerate the
properties that a working resource can have, rather than requiring a
person to scan through the protocol to find them.  I'll add this
enumeration to the working resource property section, and make sure to
include DAV:workspace in that list.

Everyone OK with that?

Cheers,
Geoff

   From: "Mark A. Hale" <mark.hale@interwoven.com>
   Date: Tue, 16 Jan 2001 22:16:04 -0800

   I think that we have now strayed off from the original intention based on
   the teleconference last Friday.  At that time, it was agreed that the
   DAV:workspace property is a property of all resources that are in the
   workspace.  A working resource is one such resource which can be in the
   workspace.

   When reading section 6.1, it says that a "working resource has all of the
   properties of a checked-out version-controlled resource".  I requested on
   the teleconference for the simple addition to 6.1 specifically stating that
   one of the properties can be DAV:workspace for clarity and it was agreed.
   There are places throughout the draft in which clarifications are added and
   I feel that this aids in clarity and fully conforms to the specification as
   written.

	   Thanks,

	   Mark




   > -----Original Message-----
   > From: ietf-dav-versioning-request@w3.org
   > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
   > Clemm
   > Sent: Tuesday, January 16, 2001 8:28 AM
   > To: ietf-dav-versioning@w3.org
   > Subject: 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 Wednesday, 17 January 2001 07:16:06 UTC