Re: ETags?

On Jan 19, 2005, at 3:56 PM, Jim Whitehead wrote:
>
> With all due respect to the engineer from Day spending a couple of 
> enjoyable
> hours procrastinating on the DAV list today, I disagree.
>
> I pressed for this language because:
>
> - a statement about dead properties in this situation without a similar
> statement about live properties begs the question of how live 
> properties
> should behave,

So what?  Let the reader beg the question. In a specification, lack
of a requirement means there is no requirement.

> - not making a statement about live properties here is ambiguous, and 
> could
> reasonably be interpreted in multiple contradictory ways
> (silence = intended assent, silence = intended prohibition),
> and leads to implementors trying to
> read spec writers' minds,

How is it ambiguous?  Intentions here are irrelevant.

> - the additional language makes it clear that servers have this 
> additional
> design freedom, if they so desire.

No, the additional language was just plain wrong.  It introduced a
bug in the protocol due to overzealous specification of things outside
the control of this particular document.  That is why we try to
avoid adding such cruft to specifications in the first place.

> The comment about testability is a red herring here, since the 
> requirement
> is at the design level. Given a specific live property, it is certainly
> possible to test whether it has a different value for different 
> bindings.

The original text said that live properties SHOULD be the same,
which was a false requirement.  The replacement that Geoff
briefly mentioned was that they SHOULD be the same unless they
were defined not to be the same.  That text would be vacuous.
It cannot be tested because a client cannot know whether changes
(or lack of changes) in the live property value are due to the
bindings, the definition, or some other activity going on behind
the server interface. The only reasonable test, therefore, is that
the property remains true to its definition regardless of whatever
actions have taken place, which is a test of the property definition
and NOT a test of the bindings specification.

In other words, given any live property, whether or not it has a
different value after the binding change is of no use nor concern
of the client.

> I'll point to the long discussions we've had on this issue as evidence 
> that
> lack of specification language on this issue does not lead to 
> experienced
> engineers drawing the same conclusion about the behavior of live 
> properties
> across multiple bindings.

And I'll point to the same discussions as evidence that if the chairs
were not so persistently obstinate in ignoring actual working group
consensus on the issues then maybe they could make reasonable
progress on drafts that should have been completed four years ago.
This issue, like many others, is whether it is ever appropriate for
experienced engineers to draw conclusions about the implementation
behind an interface, as opposed to simply reading the specification,
concluding that it defines the interface, and not assuming anything
about what happens beyond what is required of that interface.

You can find the answer to that question in any basic text on
Software Engineering -- it does not need my opinion to justify it.

....Roy

Received on Thursday, 20 January 2005 01:07:17 UTC