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:37:14 UTC