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

+1

Clarifying the distinction between requirements (optional or  
mandatory) and capabilities that may impose no behavioral requirement  
appears to be useful as Prasad notes.

Argument that capability not understood by client may not impact  
client policy processing seems reasonable in this limited case, yet  
use of optional appears to confuse. Perhaps such assertions should be  
marked with "advisory" attribute to indicate no need to include in  
intersection processing?

This might fit with argument that such assertions should be ignored  
in policy processing to reduce client impact, yet can be stated to  
allow appropriate service provider selection.

regards, Frederick

Frederick Hirsch
Nokia


On Sep 25, 2006, at 4:36 AM, ext Sergey Beryozkin wrote:

> 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 ofcapabilities 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
>
>
>
>

Received on Wednesday, 27 September 2006 15:11:32 UTC