Re: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

Chris

Thanks for the clear explanation, makes a lot of sense.

I think the distinction is whether we are talking what contributes to  
a "contract" versus what is advisory (i.e. not necessarily part of an  
agreement).

regards, Frederick

Frederick Hirsch
Nokia


On Sep 28, 2006, at 1:17 PM, ext Christopher B Ferris wrote:

>
> Frederick wrote:
>
> > I think we are getting lost with the words "capability" and
> > "requirement" when I suspect the original meaning was very simple:
> > clients have capabilities expressed by policy, providers have
> > requirements expressed by policy, and an intersection indicates a
> > match of capabilities and requirements.
>
> Taking my chair hat off to engage in some technical discourse...
>
> <hat mode="off">
> Actually, providers have capabilities and clients have requirements  
> at times. An example of this
> is reliable messaging. Typically, it is the consumer/client that  
> wants to ensure that a message is
> delivered. Thus, the WS-RX RM Policy assertion is typically  
> expressed as wsp:Optional='true'
> by the provider, to indicate that it supports the capability  
> expressed by that assertion. The client would
> then express a single alternative, either with, or without the  
> wsrm:RMAssertion for intersection purposes.
> If present, then it requires RM. If absent, then it doesn't. If  
> both express with wsp:Optional='true' then
> something else needs to factor into the intersection to select the  
> preferred alternative (although we haven't
> got anything in the framework for that, but it can be handled  
> outside the framework one would expect).
>
> The tricky case comes into play when policy is used to express a  
> provider-only assertion such as
> auditing, which is not manifested on the wire, and which the client  
> really doesn't need to understand/comply with
> in order to interact with the service provider.
>
> I think that the question becomes, do we want/need WS-Policy to be  
> able to handle such cases where a
> policy subject is decorated wth a policy alternative that includes  
> an assertion that is relevant only to
> one of the participants in the interaction/exchange?
>
> Given that there are other mechanisms by which a particpant role  
> (consumer or provider) can be configured
> to effect a capability as a requirement of processing (deployment  
> descriptors and the like), I would think that
> maybe we should consider any expression of unilateral  
> "requirements" as a v.next item. What is most important
> is that we enable the framework such that a provider can  
> communicate to the client those capabilities that
> it supports and the set of those capabilities that are required for  
> successful interaction from the perspective
> of both the provider and the consumer of a service.
> </hat>
>
> 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 09/28/2006 09:10:20 AM:
>
> >
> > I think we are getting lost with the words "capability" and
> > "requirement" when I suspect the original meaning was very simple:
> > clients have capabilities expressed by policy, providers have
> > requirements expressed by policy, and an intersection indicates a
> > match of capabilities and requirements.
> >
> > This is different from the concept of a client not needing to  
> process
> > or be aware of provider assertions that do not impact what is on the
> > wire, and removing/ignoring these advisory assertions from the
> > provider policy before/when performing intersection.
> >
> > However a point made later in the thread indicates that a client
> > still must understand these, which I think is also your point  
> Sergey.
> >
> > Is it worthwhile to mark assertions that do not impact messaging
> > (e.g. as advisory or local), thus removing issue of "optional" for
> > these, allowing them to be ignored in intersection yet still
> > understood legally?
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia
> >
> >
> > On Sep 27, 2006, at 1:31 PM, ext Sergey Beryozkin wrote:
> >
> > > Hi Frederick
> > >
> > >>
> > >> No, because it is meaningless to "ignore" an assertion that is
> > >> always  applied by the provider, even if it is advisory to the
> > >> client. In  other words, it is not ignored in associated impact,
> > >> even if client  chooses to treat as advisory and "ignore" it.
> > >
> > > Would you agree that it would be useful to think of any assertion
> > > listed in a given policy as something which is always supported by
> > > their provider  ? In other words they're guaranteed to be  
> supported.
> > > Irrespectively of how assertions are marked they're supported by
> > > their provider and not ignored...
> > >
> > > Thanks, Sergey
> > >
> > >>
> > >> No, because it is meaningless to "ignore" an assertion that is
> > >> always  applied by the provider, even if it is advisory to the
> > >> client. In  other words, it is not ignored in associated impact,
> > >> even if client  chooses to treat as advisory and "ignore" it.
> > >>
> > >> -- non-wire assertion states something will be done (e.g.  
> logging)
> > >> -  this happens, so is not optional.
> > >> -- client views this as advisory, so ignores in making request,
> > >> but  this is not the same as assertion being ignored in entire
> > >> process.
> > >>
> > >> The issue here is that optional has a much different meaning than
> > >> advisory.
> > >>
> > >> regards, Frederick
> > >>
> > >> Frederick Hirsch
> > >> Nokia
> > >>
> > >>
> > >> On Sep 27, 2006, at 12:45 PM, ext Glen Daniels wrote:
> > >>
> > >>>
> > >>> Hi Frederick:
> > >>>
> > >>>> It is difficult to combine the concept of optional with its
> > >>>> normalization implications with flagging items that can be  
> ignored
> > >>>> without implication of actual impact.
> > >>>
> > >>> Why is that?  Optional means that there is both an acceptable
> > >>> alternative without this assertion, and one with this
> > >>> assertion.   Isn't
> > >>> that the same thing as saying that the item can be ignored at  
> the
> > >>> whim
> > >>> of the consumer?
> > >>>
> > >>> This seems true regardless of whether the given assertion has an
> > >>> "impact" vis. the wire messages.
> > >>>
> > >>> --Glen
> > >>>
> > >>>
> > >>
> > >
> >
> >

Received on Thursday, 28 September 2006 17:33:48 UTC