Re: Ignorable assertions and interoperability

Hi Chris

"I guess I don't understand why strict mode presents interoperability 
challenges. We have both strict and lax mode intersection for a reason. 
Those policy consumers that don't want to ignore assertions that are 
marked as ignorable can use strict to achieve that objective. Those that 
are okay with ignoring what is marked ignorable can use lax mode. The 
policy consumer has the choice to do whatever they feel is right for 
their circumstances. "

I agree. From the consumer's perspective we have no issues at all.
The things are slightly different from the provider's perspective though.
Provider marks the assertion as wsp:ignorable=true so that it can be ignored for the intersection purposes. Otherwise why else would the provider do it ? If the provider wants the assertion be understood always then it would just expose that assertion as the normal required assertion.
But the provider does not aware of what mode consumers will be using. By marking the assertion as ignorable the provider can get some consumers fail to consume the service if they work in the strict mode. Yes, that's what consumers chose to but I think it's not something a provider will really want... So it's a possible interop concern at the WS-Policy level

Do you see what I mean ? Would you agree ?

Cheers, Sergey



  ----- Original Message ----- 
  From: Christopher B Ferris 
  To: Sergey Beryozkin 
  Cc: public-ws-policy@w3.org ; public-ws-policy-request@w3.org 
  Sent: Wednesday, February 21, 2007 12:32 PM
  Subject: Re: Ignorable assertions and interoperability



  Sergey, 

  Thanks for elaborating. 

  Please see my inlined comments below. 

  Cheers, 

  Christopher Ferris
  STSM, Software Group Standards Strategy
  email: chrisfer@us.ibm.com
  blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
  phone: +1 508 377 9295 

  public-ws-policy-request@w3.org wrote on 02/21/2007 04:36:19 AM:

  > Hi Chris 
  >   
  > Thanks for your comments. 
  >   
  > I agree, I should've created a bug with a specific proposal rather 
  > just suggesting (the editors :-)) to do some revisioning of the primer's text. 
  >   
  > One goal of this email was to explain why I was concerned about the 
  > interoperability statement during the concall as I promised at the 
  > time to reply in email... 
  > As far as wsp:ignorable and WS-Policy interoperability were 
  > concerned, one possible take on it can be that using wsp:ignorable 
  > might cause at the moment at least WS-Policy-level interoperability 
  > problems due to third-party consumers using a strict mode. This is 
  > one interop concern. 

  I guess I don't understand why strict mode presents interoperability 
  challenges. We have both strict and lax mode intersection for a reason. 
  Those policy consumers that don't want to ignore assertions that are 
  marked as ignorable can use strict to achieve that objective. Those that 
  are okay with ignoring what is marked ignorable can use lax mode. The 
  policy consumer has the choice to do whatever they feel is right for 
  their circumstances. 

  > As far as a provider is concerned, I believe a provider's motivation
  > to mark the assertion as wsp:ignorable is to try to reach with the 
  > (assertion) message to as many requesters as possible and yet 
  > continue to interoperate at the ws-policy level with ideally every 

  Agreed. 

  > requester out there. Thats's another possible view on what wsp:
  > ignorable means to the provider as far as a ws-level interop is concerned. 
  > Then there's on the wire interoperability which is what was referred
  > to during the call. 

  I still don't understand the interop concern. 

  >   
  > Hopefully this explains the reason behind the message I've sent. 
  >   
  > I've reviewed the primer and the guidelines yesterday and I've seen 
  > just a few references to the interoperability term. As far as wsp:
  > ignorable and interop are concerned, section 2.7 adequately refers 
  > to both on the wire interop and the ws-policy level interop 
  > (implicitly by advising to be aware of the impact of this attribute 
  > on the compatibility of policies). 
  > I'll add a bug with a proposal to add a minor update to that section
  > (with respect to referring to interop). Specifically, I'll propose 
  > to add a text sent by yourself earlier on the ignorability being at 
  > the discretion of the requester. 
  >   
  > Cheers, Sergey 
  >   
  >   
  > ----- Original Message ----- 
  > From: Christopher B Ferris 
  > To: Sergey Beryozkin 
  > Cc: public-ws-policy@w3.org ; public-ws-policy-request@w3.org 
  > Sent: Tuesday, February 20, 2007 12:52 PM 
  > Subject: Re: Ignorable assertions and interoperability 
  > 
  > 
  > Sergey, 
  > 
  > Would you please log this as a bug against the primer and guidelines
  > so that it can be tracked? 
  > 
  > Also, it would help to have specific areas of the primer and 
  > guidelines that mention interoperability 
  > so that we can focus on what exactly needs to be changed. 
  > 
  > Finally, if you could provide a proposal to address your concerns, 
  > that would help greatly towards 
  > closing the issue. 
  > 
  > Cheers, 
  > 
  > Christopher Ferris
  > STSM, Software Group Standards Strategy
  > email: chrisfer@us.ibm.com
  > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
  > phone: +1 508 377 9295 
  > 
  > public-ws-policy-request@w3.org wrote on 02/20/2007 05:52:22 AM:
  > 
  > > Hi 
  > >   
  > > During the latest concall it was recommended to advise not to use 
  > > ignorable assertions if the interoperability would be affected...I 
  > > thought it was a strong statement at a time. 
  > > The reason for that was that I was assuming at a time a WS-Policy 
  > > level interoperability was referred to. 
  > > Most of the time it's obvious what interoperability the spec/primer 
  > > texts refer to, but I feel it would be useful to revisit (in the 
  > > primer and guidelines) all references to the 'interoperability' 
  > > terms and qualify them as appropriate... 
  > >   
  > > Cheers, Sergey Beryozkin