Re: 2004-02-12 Action Item: Clarification to the OperationName feature

Jonathan Marsh wrote:

>Thanks for your responses.  I think many of them need to be incorporated
>into the OperationName proposal, though some might need to go into the
>Part 1 spec.  Minor comments inline below.
>
>  
>
>>-----Original Message-----
>>From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
>>Sent: Wednesday, February 25, 2004 8:26 AM
>>To: Jonathan Marsh; Umit Yalcinalp
>>Cc: www-ws-desc@w3.org
>>Subject: Re: 2004-02-12 Action Item: Clarification to the
>>    
>>
>OperationName
>  
>
>>feature
>>
>>Hi folks:
>>
>>    
>>
>>>>[description of using unique GEDs to map to operation names]
>>>>        
>>>>
>>>This fits nicely into my concept of a style, less nicely into my
>>>concept of a feature declaration.  This is reflected in the
>>>      
>>>
>component
>  
>
>>>model - a style would not change the mapping to the component model,
>>>a built-in feature would.
>>>      
>>>
>>Does the style attribute exist in the component model somewhere?  I
>>    
>>
>would
>  
>
>>think it would have to.  Assuming yes, then I don't see much
>>    
>>
>difference
>  
>
>>between another style URI and another feature URI.  As long as either
>>    
>>
>one
>  
>
>>can be used to confirm that the OName feature has been satisfied,
>>    
>>
>we're
>  
>
>>good.
>>    
>>
>
>Yes, the style attribute value is reflected in the component model.
>I'll leave it up to others whether they want to propose such a style.
>  
>
Jonathan,

There seems to be two distinct usage of the term "message" (one per 
Part1) and you seemed to be using it not to refer to the GEDs which we 
now rename as "element" from "message", but to the entire envelope as 
you indicated in [2].
I just would like to comment that the "style discussion" we are having 
pertains to the "element"s (GEDs) only, but not to the content of the 
envelope.

The reason I just want to stress the distinction is that a style only is 
concerned about the GEDs, features may be applicable to the entire 
envelope. A style can not dictate what happens in the envelope, but a 
feature can. So, the distinction is not about what appears in the 
component model. That is orthogonal to this discussion.

If we were to define that there was another style which indicated that 
"all GEDs" are unique (and indicated by the styleDefault attribute in an 
interface), the OperationName feature definition can encorporate that 
style in its definition, just like RPC style is currently incorporated 
in its definition. So, the OperationName feature can include this new 
style, but can not enforce it just like we can not enforce the RPC style.

If you recall, my original proposal for solving the "uniqueness on the 
wire" problem was to require that all GEDs to be unique [1]. You can 
consider this as a "style" and you seem to be discussing the same thing 
in this thread. However, the wg did not want to require WSDL to restrict 
how an operation is expressed per the decision in the November f2f [4] 
and we decided to solve this problem not with a requirement on the way 
the GEDs are expressed (hence by a "style"), but by defining a "feature" 
that allows a variety of options on how the operationName can be 
inferred instead.

I hope this clears why style is not interchangeable with the way we are 
defining the OperationName feature.

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0076.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0208.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0059.html

--umit

<rest_deleted/>