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

RE: DAV:displayname with versions

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 11 Aug 2003 13:48:36 -0700
To: "'Geoffrey M Clemm'" <geoffrey.clemm@us.ibm.com>
Cc: <ietf-dav-versioning@w3.org>, "'webdav'" <w3c-dist-auth@w3c.org>
Message-ID: <00eb01c36049$ef8425c0$f8cb90c6@lisalap>

Yes, but support for RFC3253 is not required for support of RFC2518.  The
core or base specification is responsible for core functionality.  I think
it encourages implementation of RFC2518 to keep it as simple as it can be,
and keeping description of optional functionality (other than locking)
outside of RFC2518 is one way to continue to keep it simple.

Another reason is that versioning functionality is newer and has seen much
less interoperability testing.  One of the considerations for RFC2518bis is
whether each feature specified meets the interoperability bar for IETF draft
standard publication.  

For drafts like binding and ordering, I agree that new properties should
have their versioning behavior specified as well as their non-versioning
behavior if necessary.  And for drafts after that, new properties may have
to be defined with their binding behavior as well as versioning.

Lisa

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] 
> Sent: Monday, August 11, 2003 12:52 PM
> To: Lisa Dusseault
> Cc: ietf-dav-versioning@w3.org; 'webdav'
> Subject: RE: DAV:displayname with versions
> 
> 
> 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 16:47:52 GMT

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