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

RE: DeltaV Lack of global properties

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 8 Feb 2001 12:15:49 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569ED.00434A3F.00@d06mta07.portsmouth.uk.ibm.com>

> > Just to be pedantic for a minute, if the client
> > was totally versioning unaware then they would be
> > unaware that versions of the resource exist, or
> > the need for "global" properties.  A versioning
> > unaware client would set a dead property on an
> > autoversioned version-controlled resource, and
> > that would be carried forward through subsequent
> > versions of the resource.
> But they would be aware of the need for a property
> like "Editor-in-Chief", they may need to get or set
> the value of this property.

I don't understand your point.  Assuming a versioning unaware client, what
characteristics of the property could they expect that are not provided for
by RFC2518?

> > Ok, so if a client was, say, versioning aware (i.e.,
> > knows versions exist) but versioning challenged<g>
> > (i.e., cannot make versioning calls) then they
> > could query the DAV:version-history property of
> > the VCR (using PROPFIND) to get to the version
> > history resource and set properties there (using
> > PROPPATCH).  It would not require any versioning
> > specific methods to implement the "global" properties.
> But they would also potentially know about the property
> "Editor-in-Chief".  And the versioning-aware client
> can look at past versions, where the "Editor-in-Chief"
> property really should not have a different value.

You missed my point, the property would be on the version history resource,
but does not require any versioning specific methods to get or set.

> So how are the two clients supposed to use the same
> property interoperably?

A versioning unaware client would have no such expectations for a property
like this.  Please explain further, I feel I'm missing it.

Received on Thursday, 8 February 2001 07:19:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC