RE: Removing a resource: A compromise that satisfies?

As I read the spec, this simply amounts to our original request.
Namely, the server is free to delete versions -- at least if it doesn't
support the version-history feature.  Because I see no way a version
would be listed in a version-tree report other than its 'own'.

So while that might be acceptable to me and Lisa, I don't think it will
be acceptable to others.  Further, our acceptance is somewhat
conditional on being able to not implement the version-history feature.
Apparently, it was suggested that a client which would prefer to use
global properties would have to use the version-history URL.  Thus
forcing us to implement this object just to get global properties.

I think Rick Rupp raised some valid points.

So I feel at this point that it is better to A) add new protocol
elements and B) make sure that a version-aware client can specify either
behavior and tell which behavior was implemented.  As elements go they
are relatively simple flags.  Since I haven't been involved in a
discussion like this before I may not understand the true impact of
protocol elements.  But it looks pretty easy from my code base.

-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
Sent: Wednesday, June 13, 2001 8:04 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Removing a resource: A compromise that satisfies?


How about an alternative approach:

Add a new postcondition to DELETE that says:

"If a server does not support the version-history feature,
then it MAY automatically delete a version resource if that version no
longer appears in the DAV:version-tree report of any version-controlled
resource."

I believe this allows John and Lisa to do what they want, without
violating the concern of several of us that a client should be able to
count on a version being preserved by a server while it is still being
referenced by another resource visible on the server.

I believe this approach is better than adding a body
to DELETE, because it does not require adding additional protocol
elements.

Cheers,
Geoff

Received on Thursday, 14 June 2001 00:41:05 UTC