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

 

> -----Original Message-----
> From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
> Sent: Wednesday, Sep 27, 2006 11:52 AM
> To: Yalcinalp, Umit; 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
> 
> 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.
> 

There is not directionality, you are right. But if you read carefully, I
have qualified the statements as to "from the providers perspective...".
In the end, the assertion is exposed and applied to a subject by some
entity to others. Within our current scope so far, it is WSDL...

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

--umit

> 
> 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 20:56:05 UTC