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

Received on Wednesday, 9 May 2007 11:04:17 UTC