RE: DAV:displayname with versions

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Lisa Dusseault
> Sent: Monday, August 11, 2003 8:04 PM
> To: 'Geoffrey M Clemm'; [email protected]; 'webdav'
> Subject: RE: DAV:displayname with versions
>
>
>
> 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.

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]

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

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