Re: DeltaV Draft

Not all resources are in a workspace. Simple as that.

Cheers,
-g

On Tue, Jan 16, 2001 at 10:16:04PM -0800, Mark A. Hale wrote:
> 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

-- 
Greg Stein, http://www.lyra.org/

Received on Wednesday, 17 January 2001 20:56:40 UTC