W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Basic Property Behavior

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 13 Jun 2001 23:16:06 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10350A364@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
Yes, this issue was raised and debated a couple of IETF's ago,
and the consensus was that the implementation burden on a server
to support versioned dead properties was not sufficient to
introduce a major source of
interoperability problems (i.e. clients that expected to be
able to version properties would not interoperate effectively
with servers that did not, and vica versa).

Note that the server defines the versioning behavior of any
server defined (and therefore, live) properties, so a server is
certainly free to make all of its server defined properties


-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]

My goals are in providing basic versioning for customers that do not
need elaborate features, but not getting in the way of more
sophisticated clients envisioned in the full DeltaV spec.

This is probably a land mine, but I thought I'd try.

I do not like the idea of versioning properties.  My customers are
interested in versioning content, not properties.  Mutable global
properties are just fine, beyond those properties specifically defined
in DeltaV as per-version (like comment and label).

So my first suggestion would be to modify the VERSION-CONTROL feature so
that someone could turn versioning for content on seperately from
versioning of properties.  Your sophisticated clients would know up
front if they hit our server and we didn't support property versioning.
They could then warn their version-aware users.

I've thought of some other expedients, most of which Lisa shot down for
a variety of reasons.  But why can't we make it optional?  If your
clients want to get huffy and not deal with a lowly server that doesn't
version properties then so be it.
Received on Wednesday, 13 June 2001 23:11:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC