RE: Review of ordering draft, version 05

> The current ordering draft tries to adopt the more precise approach of
> RFC3253. In particular, by inheriting from RFC3253 it gets
> 
> - (IMHO) a better error marshalling as RFC2518,
> - precise definitions of what must happen upon executing a method
> (pre/postconditions).

Actually, I agree that RFC2518 has a better error marshalling mechanism
*and* that precise definitions of what must happen upon executing a
method are all good things. I think the concept of preconditions and
postconditions is a good concept and helps make a specification more
complete.

But, here's what I definitely don't want to *lose* in the process.
 - the ability of a specification reader to digest a piece of the
specification, and basically "get it"
 - the clarity of the standard MUST, MAY, SHOULD language
I think we're in agreement on this now and I look forward to seeing your
revised language-- I will review it all to see if it all makes sense to
me then.

A couple more subtle topics now...

 1. I'm a little worried that we're starting to lose the richness of
having error codes from 100 to 999 available by using only 403/409.  For
example, when ordered collections aren't supported in a given location,
why aren't we using 501?  If a segment listed in the ordering is not
found, why would the server return 409 with
(DAV:segment-must-identify-member) rather than a 404 Not Found response
code (either on its own or in a body)?

 2. Are we possibly making things confusing by introducing a
postcondition "code" like (DAV:ordering-type-set) for something that
MUST be done?  It makes it seem like the server might choose not to set
the ordering type, create the collection anyway, and respond with 409
containing <DAV:ordering-type-set/>.  Wouldn't a total failure to do
some required behavior normally be defined as a 500 response?

Thanks,
Lisa

Received on Friday, 14 February 2003 19:28:24 UTC