W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: DAV:displayname with versions

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 11 Aug 2003 15:51:37 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: ietf-dav-versioning@w3.org, "'webdav'" <w3c-dist-auth@w3c.org>
Message-ID: <OFC75E4736.01C6BBF5-ON85256D7F.006C4340-85256D7F.006D1932@us.ibm.com>

I agree that we want to finish RFC2518bis in a finite amount of time,
but I disagree that versioning behavior of RFC2518 properties should be
defined in a separate draft.  Any new WebDAV draft should fully define
the behavior of any live property it defines, and versioning is 
a standard part of the WebDAV family (after all, it is "WebDAV", not
"WebDA" :-).

Cheers,
Geoff

"Lisa Dusseault" <lisa@xythos.com> wrote on 08/11/2003 02:04:24 PM:

> That isn't quite the Xythos WFS behavior.  If you MOVE a VCR, its
> displayname changes to the current name.  Thus the displayname changes 
for
> all the versions as well. They aren't entirely immutable, in other 
words. 
> 
>  I wouldn't put the versioning behavior of properties in RFC2518bis,
> however, we need to keep changes there down so we get finished in finite
> time and get draft standard status with tested interoperable features. 
If
> we think we can specify property behavior for versioning it could just 
as
> easily be done in a separate short draft.
> 
> Speaking of this, what are the issues for the binding draft and the 
behavior
> of live properties?  Does the binding draft sufficiently cover what 
happens
> with versioning in the mix?
> 
> Lisa
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org 
> > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
> > Sent: Monday, August 11, 2003 10:46 AM
> > To: ietf-dav-versioning@w3.org; webdav
> > Subject: RE: DAV:displayname with versions
> > 
> > 
> > 
> > Yes, 3253 leaves the definition of versioning behavior for 
> > live properties up to the standard that defines those live properties.
> > 
> > 
> > So we should probably try to define the versioning behavior for 2518 
> > properties
> > in 2518bis.  In general, the simplest default versioning 
> > behavior for a property such as DAV:displayname is to treat 
> > it the same as a dead 
> > property,
> > i.e. it is an immutable copy of the value of that property on 
> > the VCR at CHECKIN time.  Does this work for folks currently 
> > doing versioning? (I couldn't quite tell from Lisa's 
> > description whether this is the Xythos behavior or not).
> > 
> > Cheers,
> > Geoff
> > 
> > Lisa wrote on 08/11/2003 01:09:58 PM:
> > > 
> > > Sure, every version must have the displayname property so 
> > you can get 
> > > it with PROPFIND.  However, no specification requires that to be 
> > > either writable or protected on a version, so on some 
> > servers it won't 
> > > be
> > writable.
> > > Also no specification requires it to be either static or dynamic, so
> > it's
> > > possible on some servers that the property would be 
> > protected, and it
> > would
> > > change whenever the value on the VCR changed.
> > > 
> > > I believe on Xythos WFS the displayname property is protected and 
> > > static
> > on
> > > versions.  It will always have the same value as the displayname
> > property of
> > > the VCR.
> > 
> > > > -----Original Message-----
> > > > From: Geoffrey M Clemm
> > > > 
> > > > There is no concept of a "global" property of a version. Each 
> > > > version is a separate resource, with its own properties. So each 
> > > > version has its own DAV:displayname property.
> > > > 
> > > > But there is a natural place to put a "global" property of a
> > > > version, namely, as a property on the VersionHistory of 
> > that version.
> > 
> > > > Horst wrote on 08/11/2003 11:47:38 AM:
> > > > > 
> > > > > Just a simple question, is the DAV:displayname of a
> > > > resource "global"
> > > > > ? Or is it possible to have different DAV:displayname(s)
> > > > for different
> > > > > versions of the same resource.
> > 
> > 
> 
> 
Received on Monday, 11 August 2003 15:53:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT