Re: Utility of Ignorable?

Hi Dave

Sorry, can you clarify what is it that you're saying in your last response ?
That AssertionWithNoWireEffects is in fact better be modelled as ignorable ?
If yes I agree.

In meantime, I'd like to say that the decision to allow
<A wsp:optional="true" wsp:ignorable="true"/> does not make "ignorable" useful.

Here's my simple analysis.

1. <Policy><A wsp:optional=true/><B/></Policy>
    
   and (omitting ExactlyOne for brewity)

   <Policy>
   <All><A/><B/></All>
   <All><B/></All>
    </Policy>

Both forms indicate that <B/> is an optional assertion in that a client may free to apply the behaviour indicated by A.

Judjibg from the above I don't think that a wsp:optional is just a shortcut, rather it's a simplier way to say the same what is expressed in the normal form about A.

2. <Policy><A wsp:ignorable=true/></Policy> means that that a lax mode client may choose to ignore it if it doesn't understand it.

3. <Policy><A wsp:ignorable="true" wsp:optional="true"/></Policy>

The group decided ([1]) that because a wsp:optional is just a shortcut leading to the two alternatives in this case, then it just means

<Policy>
<All><A wsp:ignorable="true"/><B/></All>
<All><B/></All>
</Policy>

I think this is completely equivalent to the normal form in 1 above. It's definitely equivalent for the strict-mode client. For the lax mode client it's also equivalent if it does understand A.
If a lax mode client doesn't understand A then the above is equivalent to

<Policy>
<All><B/></All>
<All><B/></All>
</Policy>

that is, it's the same as if the lax client chose to ignore the first alternative containing <A/> and chose the second one containing only B.

Therefore, according to this solution, wsp:ignorable is a duplicate of wsp:optional.

IMHO to make wsp:ignorable useful more work will have to be done (in v.next ?) so that the spec clearly seperates the two attributes or else just have the single attribute only rather than 2 ones

Cheers, Sergey

[1] http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0095.html


----- Original Message ----- 
From: "David Orchard" <dorchard@bea.com>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>; "Felix Sasaki" <fsasaki@w3.org>
Cc: <public-ws-policy@w3.org>
Sent: Wednesday, May 09, 2007 5:29 PM
Subject: RE: Utility of Ignorable?


What about the case where the AssertionWithNoWireEffects is optional?
The service provides policy such that the client can choose the endpoint
with or the endpoint without the behaviour. 

Maybe the NoWireEffect is a particular privacy policy, so clients will
choose which privacy policy the service will do.  But this is also
ignorable and not required.

Cheers,
Dave

> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
> Sent: Wednesday, May 09, 2007 4:04 AM
> To: 'Felix Sasaki'
> Cc: David Orchard; public-ws-policy@w3.org
> Subject: RE: Utility of Ignorable?
> 
> 
> Hi
> 
> Do you think wsp:optional in <assertionWithNoWireEffects 
> optional="true"> has any semantics, where 
> assertionWithNoWireEffects means that the client does not 
> need to do anything on the wire even if it recognizes this assertion ?
> The reason wsp:ignorable is here is because the above is 
> considered a "lie".
> Therefore wsp:optional=true has semantics. My point is that 
> to make wsp:ignorable truly useful and unambiguous the 
> combination of wsp:optional=true and wsp:ignorable=true 
> should be prohibited. 
> 
> Cheers, Sergey
>  
>  
> -----Original Message-----
> From: Felix Sasaki [mailto:fsasaki@w3.org]
> Sent: 09 May 2007 05:12
> To: Sergey Beryozkin
> Cc: 'David Orchard'; public-ws-policy@w3.org
> Subject: Re: Utility of Ignorable?
> 
> Sergey Beryozkin wrote:
> > Hi
> >
> > I've always found it difficult to accept a "lie" argument 
> :-), simply 
> > because it does not sound like a technical argument.
> > The spec says that wspolicy:optional has no semantics, it's just a
> shortcut,
> > but the "lie" argument implies that there're semantics 
> associated with 
> > the wspolicy:optional.
> >   
> 
> note that Dave wrote "Where a service does not want to "lie" 
> about an assertion being applied, it will mark that with 
> Optional="false" and ignorable=true.". That is, only the 
> combination of Optional and ignorable has semantics.
> 
> Felix
> 
> > At the same time, using optional=true and ignorable=true at 
> the same 
> > time does not make sense, I agree, and as far as I remember this 
> > combination
> was
> > considered ok by referring to the fact that 
> wspolicy:optional has no 
> > semantics, it's just a shortcut.
> > IMHO, to make wspolicy:ignorable truly useful (and strict/lax modes 
> > which
> I
> > like really work) the spec (maybe in v.next) should make it illegal 
> > the "optional=true and ignorable=true" combination, both in compact 
> > and normal forms (that is, if it's ignorable then it's 
> present in all 
> > alternatives -
> so
> > that strict mode can really work). Otherwise people will 
> keep asking : 
> > why use wsp:ignorable if wspolicy:optional=true works ?.
> > Also it would help somehow to do some kind of validation which would
> verify
> > that ignorable assertions do not involve optional 
> behaviours affecting 
> > the wire. That way only truly ignorable assertions could be 
> marked as
> ignorable,
> > and using wspolicy:optional=true would not work...Likewise, if the
> assertion
> > is marked as optional then it would help to have some kind of 
> > certification/verification procedure to check that this assertion is
> indeed
> > pointing out to the optional behaviour, not the ignorable aspect of 
> > the provider's capabilities
> >
> > We wanted something like wsp:ignorable to mark assertions which 
> > unaware clients can ignore and aware clients may choose to 
> apply. In 
> > our original proposal we asked for ws:optional true to be 
> stripped of 
> > any semantics (no "lie" argument), as it seemed like the simpliest 
> > option; the decision was
> to
> > introduce wsp:ignorable.
> >
> > Thanks, Sergey
> >
> >
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org
> > [mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
> > Sent: 08 May 2007 20:27
> > To: public-ws-policy@w3.org
> > Subject: RE: Utility of Ignorable?
> >
> >
> > I now understand the rationale better.  Where a service 
> does not want 
> > to "lie" about an assertion being applied, it will mark that with 
> > Optional="false" and ignorable=true.  A client can choose 
> lax mode to 
> > guarantee intersection with such assertions, or strict mode 
> to ensure 
> > that only those it knows about will be intersected with.
> >
> > Cheers,
> > Dave
> >
> >   
> >> -----Original Message-----
> >> From: public-ws-policy-request@w3.org 
> >> [mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
> >> Sent: Thursday, May 03, 2007 5:02 PM
> >> To: public-ws-policy@w3.org
> >> Subject: Utility of Ignorable?
> >>
> >>
> >> Hi all,
> >>
> >> As I did the update to the primer for 4414, it became glaringly 
> >> obvious that I couldn't see the utility of Ignorable when 
> Optional is 
> >> available.
> >> The EOL assertion is a great example of this.  The table in
> >> 3.8.4 shows the boolean combinations.
> >>
> >> When Optional="true", ignorable means nothing to the client.  
> >> When Optional="false", then Ignorable has some impact.  But we see 
> >> the *only* difference between Ignorable=true and 
> ignorable=false is 
> >> when the client does not know about the assertion and lax 
> processing 
> >> is done.
> >>
> >> We have effectively addeed Ignorable for the sole scenario 
> of where 
> >> optional=false and we want lax intersection clients to produce an 
> >> intersection.  But this doesn't seem like a tremendously useful 
> >> scenario to me.  I would think that a service would just want 
> >> optional=true and be done with it!
> >> Or, if it is really required, then why would it want lax 
> clients to 
> >> produce an intersection?  It could just put optional=false and be 
> >> done with it.
> >>
> >> Your thoughts?  I don't want to raise this as a bug quite 
> yet because 
> >> perhaps a quick bit of explanation will do it.
> >>
> >> Cheers,
> >> Dave
> >>
> >>
> >>     
> >
> >
> >   
> 
> 
>