Re: Simplifying the meaning of assertions and wsp:optional

Hi Umit

Thanks... 

Is the current practice is something which is written in stone ? For some reasons which I don't understand you believe that having two explicit alternatives (simple case) instead of the equivalent wsp:optional shortcut
is backward incompatible. I'd like to understand what are sideefects of dropping this attribute. Implementers will be upset ? I doubt it. If I were to implement the intersection algorithm then I'd be certainly not :-)
Don't see any issues at the xml (validation/parsing) level either... Surely, existing engines would support wsp:optional even if it were dropped. The only possible sideeffect is that there might be a policy author's tool which, instead of using explicit alternatives for optional assertions uses wsp:optional, which is not a big issue IMHO.

Do you still feel dropping wsp:optional would be too disruptive ? 

To be honest this is not something I'd like to spend a lot of time disagreeing about :-) I feel I have a basic/simple and valid scenario and I know I can 'misuse' wsp:optional for it to work. I'd happy if improved wording suggestions you're planning to write about will address my current concerns. One of the suggested options below was about improving the wording...

Specifically, I'd like, without 'feeling guilty' that I'm overusing wsp:optional, be able to express that my service has a feature/capability/property/requirement (whatever is the best term out there) which I'd like to be visible in such a way that those requesters which can understand what it means can 'behave on it' by using  it for choosing my service among similar ones and those which don't can safely ignore it as they will get from my service whatever they want anyway without understanding this assertion.

Please note :
* this is not about any workarounds to bypass an intersection engine; policy-aware requesters may or may  not have priori requirements and they should be able to proceed in either case.
* this is not about provider-only policies which can not be usefully understood by requesters.

Thanks, 
Sergey Beryozkin
Iona Technologies



  A Big -1 to dropping Optionality. It is completely backwards incompatible with the current practice and existing assertions. Our charter indicates that we should retain backwards compatibility as a goal. 

  Explaination of what it is should not require us to drop the functionality. 

  I will write more about some wording suggestings in a different email.  

  --umit




----------------------------------------------------------------------------
    From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
    Sent: Friday, Sep 29, 2006 9:05 AM
    To: public-ws-policy@w3.org
    Subject: Simplifying the meaning of assertions and wsp:optional 


    Hi there

    After reading and reflecting on a lot of interesting messages on what wsp:optional means, on what is the differences between requirements and capabilities are and what provideres and requestors should do about various types of assertions, I'd like to offer to your attention a modest proposal on simplifying the way assertions and wsp:optional are covered in the WS-Policy Framework and primer/policy guidelines. This is all really based on what I've learnt form the others while reading those emails and from the spec... 

    The following is how (in a simplistic way) we might want to talk about assertions and wsp:optional.

    1. Any policy assertion, either marked as optional or not, is first and foremost is a requirement. It's a requirement to a requester to understand it and do something about it. What is it that a requester should do is part of a policy assertion documentation/spec. 
    In many cases a requirement would require a requester to make a commitment to engage in some kind of activity (direct or out-of-band) during the interaction.
    Alternatively, a requirement can simply be "to understand it and use it for choosing a given provider among other providers". In a sense, a requester should do nothing here but use it during the selection process, and this in itself encapsulates a requirement : an ability to use it during the selction process.

    Requirement is a capability and should be used interchangeably. It's a capability because it is something a provider knows about and can do something about. It's a requirement because a client needs to do something about it (engaing in a behavior, using for selction, etc )

    2. Assertion may or may not be optional. This *only* means that a requester is given an option to ignore a given requirement. No assertion can be ignored by a provider. Provider is guaranteed to support all assertions. Optionality is something which is only for a requester to worry about.

    3. Assertions must be understood by both parties. Spec says about it already, but it's worth highlighting it.

    Given above 3 points, we can state that an assertion like sp:HttpsToken and oasis:replyInTenSecs are equal WS-Policy citizens because in both cases there's something a client can do about them. In the former case
    a client will understand that it needs to use HTTPs in order to be able to talk a provider. In the latter case a client will understand that a service is very responsive and might use this fact as a basis for choosing this provider among others.

    Now about wsp:optional (based on above 3 points).

    Two options are proposed :
    Option1. Retain wsp:optional but explain that wsp:optional is just a syntactic shortcut to nominate a requirement as being optional for a requester to understand/do anything about. As well captured elsewhere, at the moment an optional "capability" in a compact form suddenly becomes a requirement in a normal form. This is confusing. wsp:optional is a way to nominate an optional requirement. 

    Option2. (Preferred) Drop wsp:optional altogether. Why ? Because IMHO it doesn't bring anything useful but the complexity. It makes it more complex for a policy engine to convert a policy alternative from a compact form to a normal one, and for policy authors to understand how to work with it and when it's appropriate to use it. 
    Lets explain clearly that for a given assertion/requirement be optional it should be avalable in one alternative and not in the other one and this is all... It will add a bt more work for a policy author, but IMHO not a lot.

    Finally :

    Point 2 above refers to oasis:replyIn10Secs assertion. A client can not really do  something about it as far as the interaction is concerned, but it still can do something about it : use it to select a provider, for ex. For such assertions not to interfere with those policy-aware clients which are not aware of what oasis:replyIn10Secs means and which may or may not have some priory polic requirements, we should recommend that when possible, policy authors should attempt to give an option to ignore such assertions by using policy alternatives as appropriate. Note no 'optional' qualifier is used here :-)

    So that's it... Does it make it a bit simplier ? Criticize away please :-)


    Cheers, 
    Sergey Beryozkin
    Iona Technologies