Subject: RE: DAV:displayname with versions

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 11 Aug 2003 13:46:27 -0400

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.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 11 Aug 2003 11:04:24 -0700

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Geoffrey M Clemm
> Sent: Monday, August 11, 2003 10:46 AM
> To: [email-masked]; 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.
> 
> 
> 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
> 
> > 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.
> > > 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.
> > >

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 11 Aug 2003 20:25:12 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, August 11, 2003 8:04 PM
> To: 'Geoffrey M Clemm'; [email-masked]; 'webdav'

May I ask what this is good for? If the DAV:displayname always equals the
last path component, it's much simpler not to have it at all. [WYes, I know
that IIS behaves the same -- however this doesn't make it right]

> with versioning in the mix?

Which reminds me that having the DAV:displayname change with MOVE is deeply
incompatible with bindings. In particular, consider one resource A with
bindings a' and a''. How does the DAV:displayname obtained from a' change if
you rename a''? Don't tell me that the property value will vary depending on
the URL you use.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 11 Aug 2003 20:30:09 +0200

> [mailto:[email-masked]]On Behalf Of Geoffrey M Clemm
> Sent: Monday, August 11, 2003 7:46 PM

Yes.

> the Xythos behavior or not).

I'd really like to see a use case that conflicts with Geoff's definition.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 11 Aug 2003 15:51:37 -0400

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 11 Aug 2003 13:48:36 -0700

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

> From: Geoffrey M Clemm [mailto:[email-masked]] 
> Sent: Monday, August 11, 2003 12:52 PM
> To: Lisa Dusseault
> Cc: [email-masked]; 'webdav'
> 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
> 
> > displayname changes to the current name.  Thus the 
> displayname changes
> for
> > 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
> > > > Also no specification requires it to be either static 
> or dynamic, 
> > > > so
> > > it's
> > > > I believe on Xythos WFS the displayname property is 
> protected and
> > > > static
> > > on