RE: Utility of Ignorable?

We did address this via issue
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4262 
Proposal here
http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0095.html 

Regards,
Prasad

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
Sent: Wednesday, May 09, 2007 8:29 AM
To: 'Felix Sasaki'
Cc: 'David Orchard'; public-ws-policy@w3.org
Subject: RE: Utility of Ignorable?


I do agree, absolutely. Moreover, by the time the v.next specification
will
be worked upon I might fail to recognize I suggested this :-). May be my
statements will simply get proven wrong by practitioners working with
current specs...

Cheers, Sergey    

-----Original Message-----
From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: 09 May 2007 16:18
To: Sergey Beryozkin
Cc: 'David Orchard'; public-ws-policy@w3.org
Subject: 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:41:29 UTC