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

RE: Utility of Ignorable?

From: David Orchard <dorchard@bea.com>
Date: Tue, 8 May 2007 12:27:08 -0700
Message-ID: <4260A18CD3F05B469E67BC6C20464EAC062B5A@rcpbex01.amer.bea.com>
To: <public-ws-policy@w3.org>

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.


> -----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 19:27:23 UTC

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