Re: DeltaV Lack of global properties

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

Instead of calling the client versioning challenged, lets just say it is
only Core versioning aware.  As section 2.1.1 states, the version
history resource is only exposed with the version history option.  But I
would expect/want "global" properties to be part of Core versioning and
not need to implement the version history option on the client and find
a server that has also implemented the version history option.

thanks,
--Barry


Tim_Ellison@uk.ibm.com wrote:
> 
> > > > [Lisa]
> > > > However, the real showstopper is the lack of resource
> > > > transparency.  Global properties, like "author" from Dublin
> > > > Core, or "Editor-in-Chief", are hidden away in VHRs.  That
> > > > means that versioning-unaware clients cannot interoperate
> > > > with versioning clients on the same set of documents.  They
> > > > can't even PROPFIND a set of VCRs to get properties which
> > > > ought to exist.
> > >
> > > [Tim]
> > > I don't have any suggestions for you here since there is no
> > > property that
> > > has the characteristic of being defined on a set of resources
> > > in this way.
> > > all I can offer is that the version history resource has a
> > > URL that the
> > > versioning unaware client can use to PROPFIND/PROPPATCH dead
> > > properties --
> > > but that would not be the same URL as any version-controlled resource
> > > (which is what I think you are asking for).
> > >
> >
> > [Lisa]
> > Yes, that's what I'm asking for.  Although it's true that the
> > VHR has a URL that a versioning-unaware client could hypothetically
> > use, this is actually useless since a versioning-unaware client
> > cannot get the URL of the VHR; it doesn't even know it's supposed
> > to look on VHRs for that property.
> 
> 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.
> 
> 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.
> 
> > The functionality of having what I call "global" properties on VCRs
> > is a requirement for many document versioning scenarios.
> 
> ACK
> 
> Tim

Received on Wednesday, 7 February 2001 12:10:38 UTC