Re: Utility of Ignorable?

Sergey Beryozkin wrote:
> 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. 
>   

I can't estimate the impact of prohibiting a combination of two units, 
where one (wsp:Optional) does not exist in the policy data model. But 
since you wrote "mabye in v.Next", you seem to agree that such 
considerations need more time and are not on our plate currently?

Regards, Felix.

> 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 15:18:15 UTC