W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: DeltaV Draft

From: <Tim_Ellison@uk.ibm.com>
Date: Tue, 16 Jan 2001 09:37:34 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569D6.0034E1F3.00@d06mta07.portsmouth.uk.ibm.com>


Pls see <tim> below.

>    - Highlight in Chapter 6 that the 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.
>
> 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. 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.

<tim>
    The properties are not inherited (so it is good that this is
    not 'obvious' :-)  The additional property is described in 7.2
    as part of the Server-Workspace Option.

    My objection to your sentence is that it further implies that
    the DAV:workspace property is particular to certain resource
    types, and it is intended to apply to *any* defined type.
</tim>

is clear as to what the property is and when it is set in the context of
the
working resources creation.  I feel that a client usage discussion would
actually make the Draft Specification harder to read.

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.

<tim>
  I agree with your observation, and agree that such a 'client usage
  discussion' would not be appropriate in the spec.
</tim>


Tim
Received on Tuesday, 16 January 2001 04:38:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT