Re: Revised positions for closed/open world assumptions

Please see my comments inlined below.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

public-ws-policy-request@w3.org wrote on 05/10/2007 05:10:31 PM:

> 
> Here's my revised estimate of the positions:
> 
> Overview
> There are roughly 3 positions that may be taken on the issue of the
> meaning of assertions in alternative(s).
> 
> 1. AIN Vocabulary flavour: 
> Any behaviour not implied by an assertion that is in a vocabulary should
> not be applied (Roughly original chris proposal)
> 
> No proponents. No further elaboration planned.
> 
> 2. AIN Closed world flavour (revised MSFT/IBM proposal): 
> Any behaviour not implied by an alternative must not be applied.  Any
> behaviors implied by assertions in an alternative must be applied. 
> 
> Questions:
> 1. Is it OK to omit Ignorable="true" Assertion?

Ignorable is ignorable by definition. It is expected that Ignorable has no 
manifestation
in the context of the exchange. So, yes, if the Intersection was performed 
in
lax mode, it is therefore included in the Intersection result. Since it is 

Ignorable, it can be safely ignored. If Ignorable is mis-used, and applied 
to 
an assertion that in fact does manifest itself in the interchange, then it 
may, or 
may not be applied at the discretion of the initiator of the interchange 
governed
by that alternative (although the correct policy expression in this case 
would
have been to mark it as wsp:Optional=true... see below)

> 2. Is it OK to omit Optional="true" Assertion?

By definition, there is no such thing in the data model or in the normal 
form
of a policy. wsp:Optional=true on an assertion manifests itself in the 
data model
and in normal form as two distinct alternatives, one with, and one without 
that 
assertion.

If Intersection yields an alternative that does not include the assertion 
marked
as wsp:Optional=true in the compact form of a policy expression, then by 
definition,
it is not to be applied. If Intersection yields an alternative that 
includes the
assertion marked as wsp:Optional=true

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

I wouldn't say guarantee, but it will certainly help improve matters.

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

I don't understand these limits to which you allude.

> 
> 3. 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. 

You haven't justified this, IMO. How does it allow the service more 
complete control?
Control over what? Do you mean service provider or consumer?

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

Huh? How so? See above. If I mark an assertion as Ignorable=true, then
by definition it is ignorable. It is intended that it not be manifested
in the interaction. It is there as an advertisement that the implied 
behavior
is being performed regardless (by which ever entity publishes the 
alternative
that includes the assertion).

Optional is defined as described above. Depending upon which of the
alternatives is compatible with the opposing endpoint's policy, either the
behavior is applied (because it is IN the intersected alternative) or it 
is 
not applied (because it is absent from the intersected alternative).

> 
> Cheers,
> Dave
>