Re: DeltaV Draft

Let me clarify: workspaces are optional, and placing resources into a
workspace are optional. Therefore, a given resource on the server might not
be in a workspace.

If a resource is in a workspace, then yes: DAV:workspace will be set.

Hmm. Reading your message more closely... it seems that you're asking that
we call out that DAV:workspace *might* exist on different resources. That
would be a bit strange, as we don't do that with most other properties. Why
treat this one differently?

Cheers,
-g

On Wed, Jan 17, 2001 at 05:54:54PM -0800, Greg Stein wrote:
> 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/

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

Received on Wednesday, 17 January 2001 21:09:44 UTC