RE: Utility of Ignorable?

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.
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 Tuesday, 8 May 2007 20:06:54 UTC