Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

Sergey I'm working on this.

William

On Oct 31, 2006, at 10:30 AM, Sergey Beryozkin wrote:

> Hi
>
> While the group is looking at what to do with wsp:local attribute,  
> I'd also appreciate some feedback on what a guideline/resoultion  
> should be on advertizing capabilities like
> <oasis:highlyAvailable/>
>
> Thanks, Sergey
> ----- Original Message -----
> From: Sergey Beryozkin
> To: public-ws-policy@w3.org
> Sent: Thursday, October 26, 2006 10:29 AM
> Subject: Re: NEW ISSUE :Clarify usage of assertions with no  
> behavioral requirements on the requester
>
> Hello,
>
> As part of the action assigned to me at the yesterday's concall,  
> I'd like to offer to your attention 4 alternative proposals on how  
> to resolve this issue which I believe have been mentioned before. I  
> hope the subsequent discussions will point to a best/preferred/ 
> least controversial/simpliest/easy to understand solution.
>
> I'd like to clarify that the purpose of resolving this issue is to  
> have a guideline to policy authors which wish to advertize some of  
> provider's capabilities. For ex, custom:free,  
> custom:infoConfidential, custom:highlyAvailable,  
> custom:replicatable which requesters can ignore or do something about.
> I'll add my own comments (S.B) to each of the proposal. However,  
> please do not consider them as something which represents the  
> position of Iona at this stage.
>
>
> Proposal1.
> Drastically simplify the meaning of wsp:optional. Explain that  
> wsp:optional marks an assertion which can be ignored by a  
> requester. In other words wsp:optional is identical in meaning to  
> wsp:ignorable. Clearly state that wsp:optional assertions are by no  
> means optional to a provider.
> Explain that wsp:optional is a shortcut which simplifies creating  
> different policy alternatives/vocabularies.
> Ex : <custom:infoConfidential wsp:optional="true"/> means a  
> requester can ignore it.
>
>
> <S.B>  IMHO this is the simpliest solution which works. IMHO the  
> current treatment of wsp:optional is too complicated. For ex, I  
> think stating that if there's something a provider always does  
> should not be marked as optional, otherwise it has to be optional  
> will only confuse the users. IMHO it's wrong to say a provider  
> optionally does MTOM, it always does it, one requester can choose  
> an alternative with no MTOM but it does not mean the provider does  
> not do it with the other requester. In other words an alternative  
> is a piece of vocabulary. If MTOM is not in the selected  
> alternative or not it does not mean that a provider has lost its  
> capability to do MTOM. Viewing wsp:optional as a simple marker to  
> indicate ignorable assertions is a very simple and working solution  
> IMHO.
> <S.B> additional advantage is that it cleanly alligns with a  
> proposed wsp:local attribute in that a user will be guided to mark  
> server-specific stuff as being wsp:local. Imagine a GUI asking a  
> question :
> * "Is this assertion must be understood by a requester", YES-normal  
> assertion.
> * "Is this assertion may be ignored by a requester", YES-multiple  
> vocabularies are created, addional question : "Can this ignorable  
> assertion be of any interest to a requester ?" NO - mark it as  
> wsp:local.
> Nothing will prevent a user by exposing <myLocalServerOnlyAssertion/ 
> > by marking it as wsp:optional. This approach will proactively  
> teach a user not to do it and only expose assertions which can be  
> of interest to a requester.
>
> Proposal 2. Similar to proposal1. Drop wsp:optional altogether and  
> find out how simple things have become. The reason it works is that  
> if we forget about wsp:optional for a second, we can easily see  
> that if one assertion is contained in one alternative and not in  
> the other one then it's an optional/ignorable assertion. Another  
> reason it works is that we can imagine policy authors using GUI  
> tools which guide them. Imagine questions like : "Is this assertion  
> must be understood by a requester" ? "Is this assertion may be  
> ignored by a requester" ? Yes to the last question will result in a  
> tool creating two alternative vocabularies.
>
> <S.B> the same comments as above
> <S.B> disadvantage is that more work will be requiored in a manual  
> edit mode.
>
> Proposal 3. Introduce a new attribute wsp:provider-only and leave  
> wsp:optional the way it is now.
>
> Ex :
>
> <Policy>
> <m:MTOM wsp:optional="true"/>
> <sp:security/>
> <!-- of potential interest to requesters -->
> <m:highlyAvailable wsp:provider-only="true"/>
> <!-- server-specific stuff, of no interst to requesters-->
> <m:myCustomServerLogging wsp:provider-only="true"/>
> </Policy>
>
> <S.B.> This works only if wsp:provider-only="true" are not stripped  
> but this means wsp:provider-only="true" pointing to server-specific  
> stuff only won't be stripped and be consistently leaked (and  
> confuse a user at a design-time). If it's stripped then we'll lose  
> <m:highlyAvailable/> which is of interest to knowledgeable  
> requesters. IMHO it's a can of worms.
>
> Proposal 4. Noop. Think of workarounds : multiple endpoints,  
> different Policies, WSDLs, etc...
>
>
> Enjoy, Sergey.
>
>
>
>
>
>
>