W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

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

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Wed, 27 Sep 2006 11:52:03 -0700
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, "ext Glen Daniels" <gdaniels@progress.com>
CC: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <20060927115203633.00000001216@amalhotr-pc>

As you have no doubt noticed, there is no notion of direction in WS-Policy.
Thus, you cannot make the distinctions that several of you have made re.
requirements and capabilities.  This has bothered me for some time now.
I guess the solution is to explicitly identify policies as being from a provider
or requester or, in other words contains requirements or capabilities.

If we agree to this then we can also make policy matching more precise wrt input and 
output messages. 

All the best, Ashok
 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Wednesday, September 27, 2006 11:42 AM
> To: Frederick Hirsch; ext Glen Daniels
> Cc: public-ws-policy@w3.org
> Subject: RE: ISSUE 3564: Optional Assertions may not be 
> usable in all cir cumstances
> 
> 
> The problem is that we are dealing with at least 3 categories 
> and trying to label them appropriately. Perhaps we should try 
> plain English.
> 
> >From a provider's perspective there are (at least) three 
> categories we
> have identified:
> 
> -- YOU and I MUST
> -- I MAY
> -- I WILL regardless of what YOU do or I WILL regardless of 
> how we communicate. 
> 
> Mathematically speaking, requirements is a subset of 
> capabilities. So the vocabulary represent the capabilities of 
> the provider regardless of the requirements that are posed in 
> addition. In this sense, folks that are using capabilities in 
> the general sense are right, but a bit misguided about the 
> application of optional="true" marker.  
> 
> In real life, I can speak English and Turkish. These are my 
> capabilities. However, I must speak to all the folks in the 
> WS-Policy wg in English because that is a requirement. 
> Otherwise, noone will understand what the heck I am talking 
> about although I can swear and get by with it. ;-) 
> 
> In the categories above, the second category is represented 
> by the wsp:optional="true" marker. It is the only one that 
> refers to a capability that requires an additional action 
> from the perspective of consumer to do sth. For example, I 
> will not respond to you in Turkish unless you start speaking 
> to me in Turkish. Thus, the only category that represents 
> capabilities but NOT requirements is the second bullet.
> (Please again lets not forget that capabilities are a 
> superset of requirements). 
> 
> The first and third categories are requirements for the provider. 
> 
> The first category is a requirement for both the provider and 
> a consumer. 
> 
> It seems to me that there is some confusion as to where the 
> optional markup can be used.  
> 
> I sense that the optional marker is sometimes used as a 
> WORKAROUND to designate a category that is to distinguish a 
> client's responsibility to choose and NOT understand the 
> assertion. Because in the end, the resulting behaviour is 
> that the assertion does not apply in the alternative. You can 
> always choose an alternative that you understand ;-). If I 
> follow the discussion, some folks may want to use it for the 
> third option as well as the second option. That is confusing 
> to me. In my opinion the applicability of the optional="true" 
> is the class of assertions that belong to bullet 2. 
> 
> >From a vocabulary perspective, we have just decided that the 
> >optionality
> only applies to the application of the assertion but that 
> does not mean the assertion is NOT present in the vocabulary. 
> This is very consistent with the English usage and consistent 
> with the categorization presented above. 
> 
> In essence, the third category is what people would like to 
> designate and treat differently. If I follow correctly, it 
> seems that the problem is arising from the fact that some 
> people are using the optional marker to label this third 
> category where the requirement is on the provider only 
> especially if clients do NOT understand the vocabulary 
> presented in the third category as it affects the 
> intersection algorithm. Perhaps we need a different 
> term/marker for that rather than overloading the usage of 
> optional if the intent is to create alternatives that are 
> actually NOT required to be understood by the consumer. 
> 
> Ote that from the requirements vs. capabilities, the 
> categories are ok.
> If I were to use a different word, constraints, I would claim 
> it would be a good label for the first bullet but not the third. 
> 
> My two cents, 
> 
> --umit
> 
> 
> 
> 
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] On Behalf Of 
> Frederick Hirsch
> > Sent: Wednesday, Sep 27, 2006 10:02 AM
> > To: ext Glen Daniels
> > Cc: Frederick Hirsch; public-ws-policy@w3.org
> > Subject: Re: ISSUE 3564: Optional Assertions may not be 
> usable in all 
> > cir cumstances
> > 
> > 
> > No, because it is meaningless to "ignore" an assertion that 
> is always 
> > applied by the provider, even if it is advisory to the client. In 
> > other words, it is not ignored in associated impact, even if client 
> > chooses to treat as advisory and "ignore" it.
> > 
> > -- non-wire assertion states something will be done (e.g. 
> logging) - 
> > this happens, so is not optional.
> > -- client views this as advisory, so ignores in making request, but 
> > this is not the same as assertion being ignored in entire process.
> > 
> > The issue here is that optional has a much different meaning than 
> > advisory.
> > 
> > regards, Frederick
> > 
> > Frederick Hirsch
> > Nokia
> > 
> > 
> > On Sep 27, 2006, at 12:45 PM, ext Glen Daniels wrote:
> > 
> > >
> > > Hi Frederick:
> > >
> > >> It is difficult to combine the concept of optional with its 
> > >> normalization implications with flagging items that can 
> be ignored 
> > >> without implication of actual impact.
> > >
> > > Why is that?  Optional means that there is both an acceptable
> > > alternative without this assertion, and one with this 
> assertion.   
> > > Isn't
> > > that the same thing as saying that the item can be ignored
> > at the whim
> > > of the consumer?
> > >
> > > This seems true regardless of whether the given assertion has an 
> > > "impact" vis. the wire messages.
> > >
> > > --Glen
> > >
> > >
> > 
> > 
> > 
> 
> 
> 
Received on Wednesday, 27 September 2006 18:54:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:41 GMT