Revised Open World/Closed World positions

Here's my rerevised estimate of the positions:

Overview
There are roughly 4 positions that may be taken on the issue of the
meaning of assertions in alternative(s).  This is shown with our typical
example and a table at the bottom.  

Provider Policy:
<Policy> 
  <A/> 
  <B/>
  <C wsp:Optional="true"/>
  <D wsp:Ignorable="true"/>
</Policy> 

Requestor Policy:
<Policy> 
  <A/> 
  <B/>
  <E wsp:Optional="true"/>
  <F wsp:Ignorable="true"/>
</Policy>

Lax intersection yields:
<Policy> 
  <A/> 
  <B/> 
  <A/> 
  <B/>
  <D wsp:Ignorable="true"/>
  <F wsp:Ignorable="true"/>
</Policy> 

Strict intersection yields no intersection.

There is a policy <Z/> that the Provider knows about, and a policy <Y/>
that the Requester knows about.  It does not matter whether these are
optional or ignorable.

1. AIN Vocabulary flavour: 
Any behaviour not implied by an assertion that is in a vocabulary should
not be applied.

No proponents. No further elaboration planned.

2. AIN Closed world flavour : 
Any behaviour not implied by an alternative must not be applied.  Any
behaviors implied by assertions in an alternative must be applied. 

Pros
This ensures that a provider will provide a "complete" description of
the behaviors and thus guarantee interop including optional/ignorable.

Cons
Pending questions, may limit providers ability to apply behaviors.

3. AIN Client Vocabulary flavour (revised MSFT/IBM proposal?):
Any behaviour not implied by an assertion that is in a client's
vocabulary should not be applied.  

4. AIN Removal (open world): 
Any behaviour not implied by any assertions in an alternative may or may
not be applied.  Any behaviors implied by assertions in an alternative
must be applied. 

Pros
Perception of "simpler" specification.  Allows service fuller control
over application of behaviors.  

Cons
Provider might not provide "complete" description.  Interop is
guaranteed but optional and/or ignorable behaviors may be missed by
clients.

A table of the WILL/WILL NOT, MUST NOT, and MAY of the requester and
provider.

Style \             WILL       | MUST NOT       | MAY         | WILL NOT
AIN Vocabulary      A, B, D, F   E                Y, Z          C
AIN Closed          A, B, D, F   E, Y, Z                        C
AIN Client Vocab    A, B, D, F   E, Y             Z             C
Open World          A, B, D, F                    C, E, Y, Z    

As best I can tell, the strong defense of the AIN Client Vocab position
is specifically for the case where a service MAY do an assertion that it
hasn't said anything about(Z), but it MUST not do anything it hasn't
said(E,Y) and it MUST do everything it has said(A,B,D).  Note, client
does F.  The difference between this and:
- fully closed: the service MUST NOT do Z, 
- closed vocabulary: the service MAY do Y additionally
- fully open: the service MAY do C, E, or Y additionally.

I realize that the point is that it is actually behaviors implied by
assertions, but that gets a bit wordy to say when we are talking about
intersection results of assertions, so I've just shortened it.  

Cheers,
Dave

Received on Wednesday, 23 May 2007 05:21:24 UTC