RE: DeltaV Draft

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 01:16:48 UTC