W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

RE: Utility of Ignorable?

From: Sergey Beryozkin <sergey.beryozkin@iona.com>
Date: Wed, 9 May 2007 12:04:00 +0100
To: "'Felix Sasaki'" <fsasaki@w3.org>
Cc: "'David Orchard'" <dorchard@bea.com>, <public-ws-policy@w3.org>
Message-ID: <EMEA-EMS1cx4vvsGOke00000256@emea-ems1.ionaglobal.com>


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


> 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
> 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
> 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 -
> 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
> that ignorable assertions do not involve optional behaviours affecting the
> wire. That way only truly ignorable assertions could be marked as
> and using wspolicy:optional=true would not work...Likewise, if the
> is marked as optional then it would help to have some kind of
> certification/verification procedure to check that this assertion is
> 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
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC