Re: Remaining issues with the bind draft -- process

On 06/04/2004, at 12:52 PM, Geoffrey M Clemm wrote:

> Thanks for speaking up!  It's folks that aren't part of the
> design team whose feedback on this point is most valuable.

The fact that I have to reconstruct design motivations from the mailing 
list when reading the spec in order to review it is demonstration of 
why more non-normative content should be with the spec. Otherwise 
responses will be driven by "that's more work for my server" or "that 
doesn't match my use case" rather than "I understand the trade-offs 
required by both extant and projected uses", which seems to me to be 
what is truly required. I've given an example of this below.

I don't feel qualified to give detailed feedback because I'm not sure 
*why* certain decisions were made.

> I agree that comprehensibility is more important than
> axiomatic minimality, but we do try to avoid duplicating
> normative information from other specs, to avoid confusion
> when those other specs are revised.

I'm talking about non-normative content. As a matter of process I think 
that writing (for example) a user guide, generates a better spec. In 
this case, the spec would be less likely to reflect the hidden 
assumptions of specific implementers. Writing explanation is like peer 
review of code.

> Were there specific parts about the BIND spec that you felt
> merited/required additional explanation?

To be honest, my comments were motivated by watching the discussion 
between (principally) Lisa and Julian, rather than reading the most 
recent BIND spec, although now I'm motivated to do that!

I know there have been arguments about DELETE not being equivalent to 
UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 
transactional and non-transactional semantics seem broken to us - 
that's one place where some non-normative content motivating these 
distinctions would help. As another (tangential) example, having a lock 
create a new resource seems, on the surface, broken to us, because 
effects caused by a failed lock creator should be rolled back at the 
server. IMO any spec specifying that behaviour should say why that's 
required. I'm sure there must be some reason for this that 
non-transactional environments require, which is outside our headspace.

As a matter of completeness: it has always seemed to me that binding is 
more fundamental than locking, and that it would be better to have the 
WebDAV spec recast in terms of bindings, with support for more than one 
binding to a resource as an implementation option. Locking would then 
be on top of that, explaining how core semantics are modified in the 
presence of locks. I know this isn't going to happen.

Antony Blakey
-------------
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the 
Spanish Civil War, George Orwell wrote that such amorality was only 
really possible, 'if you are the kind of person who is always somewhere 
else when the trigger is pulled'.
   -- John Birmingham, "Appeasing Jakarta"

Received on Tuesday, 6 April 2004 00:13:17 UTC