RE: Review of ordering draft, version 05

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, February 14, 2003 6:25 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
> ...
>
> > I agree that the condition itself can be expressed in a more stringent
> > manner. However, I strongly disagree with the second sentence: all
> > pre/postconditions are MUSTs (by definition), and therefore the
statement is
> > (a) redundant and (b) - for consistency - it would have to be repeated
on
> > each an every condition.
>
> Yes, I agree that consistency helps make a spec readable.  What I'm
> proposing is to put a phrase such as "the server MUST..." on each and
> every condition. I will propose specific sentences if necessary, but I'm
> not sure I even understand each postcondition (which is itself clearly a
> problem).

I will look into rewriting the condition explanations. If there's a specific
one which you currently don't understand (after having clarified that all of
them are MUSTs), I would be interested to hear which.

> The reason I suggest this redundancy is because I talk to a lot of
> people who implement WebDAV yet who haven't read every word of every
> spec.  I remember my first job working on WebDAV in 1998 and I just
> browsed through the WebDAV and HTTP specs lightly. Then when a developer
> would ask me a specific question about something like how range headers
> worked, I'd look up that specific section. Usually, I could find the
> answer without having to integrate massive amounts of text from various
> sources, because in fact RFC2616 and RFC2518 are fairly well-written.
>
> Since this is the way specifications are used, a well-written
> specification *does* have a lot of redundancy. In writing essays,
> students are told to say what you're going to say, say it, and then say
> what you said. A specification is not a piece of code, to be executed by
> a computer which can load every line into memory and compile before
> executing. It's a puzzle that's too big to be seen at once, so instead
> each reader picks up a small piece of the puzzle at a time and tries to
> understand some of the picture just from that piece. A pragmatic
> approach to writing a successful specification takes that into account
> and provides enough context in each puzzle piece so that piece makes
> sense.

All true, but...

On the other hand, a spec must be precise. RFC2518 currently is very
verbose, but neglects to precisely define everything. For example: the
various PROPFIND types are mainly documented by example. A similiar problem
exists for the definition of error handling. So I really don't accept the
current version of RFC2518 as good example.

RFC3253 on the other hand is very precise, but definitively lacks examples
(the price for adding examples would have been a much much bigger spec,
which is a problem in itself).

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).

In addition, the draft tries to give more examples than RFC3253 does. In
this particular case, this can easily be afforded because the spec is so
much smaller.

So, the ordering spec tries to use the same approach as RFC3253, ACL and the
bindings spec. If there's something fundamentelly wrong with this approach,
it also applies to these other RFCs and drafts, and I'd like to see a more
general discussion about that.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 14 February 2003 19:05:54 UTC