Re: GULP as pure model, draft 2

Geoffrey M Clemm wrote:
> 
> Looking better.  A few suggested changes below:
> 
> Lisa wrote on 01/16/2006 02:55:16 PM:
> 
> 
>  > 3. A resource cannot be directly or indirectly locked with an exclusive
>  >    lock and any other lock at the same time, as these would be
>  >    conflicting.
> 
> I believe it is clearer to state this requirement in terms of what
> operations must fail, because otherwise an implementor
> could mistakenly conclude that the second
> request could succeed, and just not result in a second lock.
> Also, there is no need to introduce the term "conflicting"
> here.  So I'd simplify this to just say:
> 
>  3. When a resource is directly or indirectly locked with an exclusive
>     lock, an attempt to lock that resource with a different lock MUST fail.

...while I agree with the comment, I still think that introducing the 
term "conflicting" makes sense; I think we need it in other parts of the 
spec.

> 7.  A lock-token MUST be submitted in any request that modifies any
>     of the following aspects of the locked resource:
> 
> 
>  > Now to address Julian's comment that we need some of this stuff to be
>  > normative so that other specs can be concise
> 
> The issue is not how precise another spec is ... the issue is that this
> document needs to make normative statements about locking for methods other
> than those defined in this specification.  For example, if a new
> PROPINSERT method is defined (that inserts values into an existing property
> value), then this model needs to normatively apply to PROPINSERT, which it
> would not if the only normative language about locking
> appears in the 2518 method definitions.

+1

>  > I propose that most requirements belong
>  > in the section where a method or header is defined
> 
> That fails to make this locking model normative to methods defined in 
> other specs.
> 
>  > -- this helps us
>  > avoid discussions of marshalling in the model
> 
> Making the model normative does not require discussions of marshalling.
> 
>  > which makes it cleaner,
>  > and keeps requirements together readably (e.g. all requirements about
>  > LOCK are in LOCK section).
> 
> This model should appear in the LOCK section.

+1

>  > Thus:
>  >   - Normative text about LOCK request goes in the section on LOCK.  E.g.
>  > creating new empty resource, refresh requirements.
>  >   - Normative text about UNLOCK request goes in section on UNLOCK.
>  >   - Model point #7 could EITHER become normative right there in the
>  > model and just change "must" to "MUST"
>  >             OR go in the section relating to marshalling of 
> submitting lock
>  > tokens, which is the If header section (ick)
>  >             OR be repeated as normative in the "Lock Tokens" section,
>  > presumably a sub-section after the model is introduced
>  >
>  > Suggestions welcome...
> 
> I suggest just making the model normative by changing "must" to "MUST"
> wherever normative statements are being made in the model.
> 
>  > We're still not yet at the point where GULP can be very cleanly
>  > introduced (although I think we're getting closer).  For example,  GULP
>  > uses "lock-token" before that term has been introduced.  Does that mean
>  > that GULP should be in RFC2518bis after the section on lock-tokens, or
>  > that it should be before and we should add a model point (number 5.5,
>  > effectively) to say that "every lock has a unique lock-token assigned
>  > by the server"?
> 
> I suggest the latter, i.e. add the clause to the model.

Yes, that would make a lot of sense.

Best regards, Julian

Received on Wednesday, 18 January 2006 16:11:41 UTC