RE: NEW ISSUE :Clarify usage of assertions with no behavioral req uirements on the requester

 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
> Sent: Tuesday, Oct 31, 2006 2:07 PM
> To: Glen Daniels; Prasad Yendluri; Sergey Beryozkin; 
> public-ws-policy@w3.org
> Subject: RE: NEW ISSUE :Clarify usage of assertions with no 
> behavioral req uirements on the requester
> 
> 
> >client still needs to 
> >understand what <oasis:highlyAvailable/> means to make any 
> >sense of it?
> 
> You are correct. The requestor must understand the assertion 
> to conclude
> that there aren't any behavioral requirements on the requestor.
> 
> 
> >I would actually propose that we should consider 
> >renaming wsp:optional to wsp:ignorable, as it seems 
> >to me that this might help to clarify the breadth 
> >of usage scenarios that this attribute enables.
> 
> 'wsp:Optional' is a simple short cut for two alternatives: 
> one with the
> assertion and one without the assertion. There aren't any semantics
> associated with this marker. Several existing assertions (out there)
> recommend the use of this optional marker. WS-Policy REC should remain
> compatible with existing policy assertions. So, I can't see the
> incremental value of renaming this attribute.

I agree. I also do not see the value of overloading the existing
attribute with a semantics that is not inherent in its definition as the
proposed naming change implies. The existing domain assertions do not
indicate "ignorable" behaviors. 

That is why another approach for this use case is needed. 

> 
> Regards,
>  
> Asir S Vedamuthu
> Microsoft Corporation

--umit

> 
> 
> -----Original Message-----
> From: public-ws-policy-request@w3.org
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Glen Daniels
> Sent: Tuesday, October 31, 2006 1:25 PM
> To: Prasad Yendluri; Sergey Beryozkin; public-ws-policy@w3.org
> Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral
> req uirements on the requester
> 
> 
> 
> Hi Prasad, all:
> 
> > If the assertion (capability) MUST be understood by the 
> > clients it must not be marked "optional", otherwise it is 
> > marked with "optional=true".
> > 
> > Why would that not work, given the client still needs to 
> > understand what <oasis:highlyAvailable/> means to make any 
> > sense of it?
> 
> +1.  I would actually propose that we should consider renaming
> wsp:optional to wsp:ignorable, as it seems to me that this 
> might help to
> clarify the breadth of usage scenarios that this attribute enables.
> 
> Just to be clear - non-ignorable (i.e. "MustUnderstand") policy
> assertions require that they be understood and agreed with in order to
> successfully use the policy alternative.  This does not 
> necessarily mean
> any particular observable effect occurs as a result of this agreement.
> (Once again, however, I note that it would be nice to have a standard
> mechanism for indicating the policy alternative selected, to 
> avoid each
> assertion author needing to craft individual SOAP headers)  Ignorable
> assertions are just that - they may be freely ignored as if 
> they weren't
> present, or freely acted upon if they are understood and agreed with.
> 
> --Glen
> 
> > Regards,
> > 
> > Prasad
> > 
> >  
> > 
> > ________________________________
> > 
> > From: public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] On Behalf Of 
> Sergey Beryozkin
> > Sent: Tuesday, October 31, 2006 9:32 AM
> > To: Sergey Beryozkin; public-ws-policy@w3.org
> > Subject: Re: NEW ISSUE :Clarify usage of assertions with no 
> > behavioral requirements on the requester
> > 
> >  
> > 
> > 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 <mailto:sergey.beryozkin@iona.com>  
> > 
> > 	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.
> > 
> > 	 
> > 
> > 	 
> > 
> > 	 
> > 
> > 	 
> > 
> > 	 
> > 
> > 	 
> > 
> > 
> 
> 
>

Received on Tuesday, 31 October 2006 22:49:39 UTC