RE: DeltaV Draft

I agree with your synopsis that the property may or may not be set for a
working resource depending whether or not the working resource was
instantiated in a workspace.  The complexity of the specification in its
current form makes it difficult to understand that this property will be set
for working resources created in a workspace.  I simply ask for the
properties to be better described.  In particular, I will be looking to see
that the DAV:workspace property is described.

	Thanks,

	Mark




> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, January 17, 2001 6:10 PM
> To: Mark A. Hale; ietf-dav-versioning@w3.org
> Subject: 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 Thursday, 18 January 2001 20:53:54 UTC