RE: Deleting versions

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Actually, I think the problem is that I (do other readers?) still
   don't look in the preconditions and postconditions for normative
   requirements.  I think of them as error/status codes, but in fact a
   lot of the postconditions make requirements.

That would be a problem, because the majority of the normative
requirements are specified in the pre and post conditions. The
introductory text provides motivation and guidance, but the
pre and post conditions are the actual specification of functionality.

   And, in the case of this requirement, the use of the passive voice
   makes it a bit of work to figure out whether the client is
   responsible or the server is responsible.

Satisfying a precondition is always the responsibility of the client, 
and satisfying a postcondition is always the responsibility of the
server.  This is now stated explicitly in the introduction.

But I agree that this could be emphasized by replacing the passive
voice with "the server MUST ...", and will do so.

   So yes, a clear statement like "The server MUST NOT allow the last
   version to be deleted" would be useful.

OK, how about if I add the following sentence to the postcondition: "A
result of this postcondition is that every version history will have
at least one version." ?

   I'd suggest saying that MKWORKSPACE can be allowed on a
   write-locked null resource, but no other DeltaV methods.

What is the (compelling :-) use case for creating a lock-null
resource before issuing the MKWORKSPACE request?

Cheers,
Geoff

Received on Monday, 4 June 2001 14:30:34 UTC