> > 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.
Tim