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

Prasad Yenduri wrote :

"I tend to attributes two types of meaning to capabilities. (1) Things the provider can do if the requester tries to engage it (e.g use of MTOM/XOP encoding). That is, optional requirements, which is the interpretation that the primer has taken. However I can see another kind of capabilities (ii) capabilities e.g. a service declares it can do but there is no requirement on the client. For example, this service receives mail for xyz.com domain, but it also routes mail to domains other than xyz.com (serves as a mail gateway). Can a service declare that "capability" as an assertion? It is useful for the (mail) client to know so that, it can send mail addressed to other domains to this service. Another example is, a service that boasts a10 msec response time. My understanding is that declaration of capabilities such as these is a valid use of policy assertions. 
 

If so, the primer / best practices doc's interpretation of capability is incomplete and perhaps misleading? It would be useful to account for the use case #2 above also. 

 

Honestly, I would like to call optional requirements just that (and not capabilities), as there may not be any capability implication to a service in general, if or not a client engages an optional requirement.  E.g. an optional requirement to follow-on an online Purchase Order request via hard-copy sent to a USPS address."



+1. 

At the moment the way wsp:optional is defined is misleading IMHO. Primer and the WSPolicy Framework spec refer to assertions marked by wsp:optional as the ones which identify behaviours which may be optionally engaged in contrast to "must be". 

The main problem with this definition is that the *key* property of such assertions is overloaded and hidden : this property is that such assertion CAN be ignored by a client. As such, policy authors will be confused as to how to use assertions for the use case #2.



Cheers, Sergey Beryozkin

Iona Technologies