Re: More detailed responses to responses...

Note: I've trimmed the comments where I just agree with Tim's response.

   >    Section 5.3, Version Selector Properties How does a client
   >    definitively figure out if a URL points to a "Version
   >    Selector", a version history, or a regular resource?
   >
   > Wouldn't it find out what it needs to know by asking the resource
   > what methods, live properties, and reports it supports?

   <tim2> I agree.  The spec does give definitive rules for identifying types
   by the presence of properties, but this is IMHO a suboptimal way of doing
   business.

Why?  For a version history, it's definitely a different resource type
(and has DAV:version-resource as its DAV:resourcetype).  For a version
selector, version, and regular resource, they are all the same "type"
(collection, html document, whatever).  The only difference between a
"version selector" html document, a "version" html document, and a
"regular" html document is that the version selector and version have
some additional properties and methods.  Are you going to put "checked-out"
in the resource type also?  How about "locked"?  These all affect what
methods apply to a resource.  Next thing you know, we'll all be given
numbers instead of names, and (wait, that's a different rant ... :-).

I actually don't care much about this one way or the other (:-).  Let's
see what Chris says about whether extending the DAV:resourcetype field
will break Microsoft clients.

   If I do a PUT to a version selector, isn't that interpreted as a write to
   the resource whose versions are represented by the version selector?

   <tim2> No, a version selector is a resource in its own right, with content
   and properties.  ...

Since this issue has arisen before, I'll add a clarifying sentence in
the core versioning model.  Note: I agree with everything 
Tim said about this issue.

   > Overwrite:F has its usual semantics, namely abort the operation if
   > a resource exists at the destination.

   OK, I like that -- it doesn't violate the principle of least-surprise.
   Please at least recommend that in the draft.

All requirements from 2518 (and 2616) apply to the versioning extensions
(i.e. it's a requirement, not a recommendation).  We normally don't
repeat those requirements (just think how long the document would be
if we did!).

   >    ... If a resource is already
   >    checked out -- can a "core-compliant" server refuse the
   > CHECKOUT request?
   >
   > The server can refuse any command (heck, it's the server after all :-).
   > To declare this behavior, set the (optional) DAV:checkout-fork property
   > to DAV:forbidden (see section 14.1.3).  Then you would return a 409
   status
   > with <DAV:checkout-of-checked-out-version-is-forbidden/> in the response
   > body of the CHECKOUT request.

   Excellent.  Please put this in the draft.

It is (in section 14.1.3 and in the advanced definition of CHECKOUT).
Or did you mean "put it in core"?  There are many servers that don't
want to implement the DAV:checkout-fork functionality, so I don't
think it should be in core.

   We also need <DAV:multiple-checkouts-forbidden/> for servers which not only
   do not allow checkout of a version that has already been checked out, but
   also do not allow checkout on any version of a resource for which any
   version has already been checked out.

That's already there: <DAV:checkout-of-version-with-descendant-is-forbidden/>
(pretty catchy name, eh? :-)

   Why is it fine for a new method to have a bunch of side effects,
   but not for PROPPATCH of a new property?

One reason is the atomicity argument.  If you've got a bunch of
properties updated in a single proppatch, if the result is just a
change to those properties, it is much more reasonable to expect the
server to be able to predict whether or not all the requests will
succeed (and fail the PROPPATCH if it does not).  If on the other
hand, one of those property updates involves a significant set of side
effects on other properties and other resources, it becomes much more
likely that the server will not be able to guess (or to guess wrong),
which means it must pre-emptively reject the PROPPATCH call (meaning
the client needs to break it up and try it separately anyway), or risk
failing in the middle and leaving the server in a state the client
does not expect.

I believe that it would lead to greater interoperation of clients and
servers if operations with side effects were clearly identified as
separate methods, so that clients would not be misled into thinking
that they can combine multiple updates into a single atomic PROPPATCH.

But I really don't care all that much about whether we marshal our
methods through separate method calls or PROPPATCH, so since I think
I've forwarded the various arguments I've heard in the past, I'll
leave this thread for others to comment on.

Cheers,
Geoff

Received on Thursday, 5 October 2000 17:58:05 UTC