Action 2004-11-11 check on operation@style (LC61a) (or REOPEN LC21 Resolution B)

Folks, 

I took the action item to explore the impact of a decision made by the
wg with respect to the style attribute at the last f2f [1]. 

We were discussing LC61a [2] and we made the decision to move style
attribute to Part2 where it naturally belongs. The nature of my action
does not concern our decision with respect to LC61a which I agree with.
The action item  concerns investigating an earlier decision of the wg
that was brought up by Asir during the discussion of LC61a with respect
to LC21 [4] that was resolved in [3]. 

It became apparent in the f2f [1] that people were unaware of the impact
of the decision made in [3] with respect to rpc style in particular. 

In LC21[3], there were two decisions taken by the wg as quoted:
(Labeled as A and B for reference)

A:  ED TODO: Add a statement like: 

The Style property may constrain both input and output, however a
particular style may constrain in only one direction. In Section 2.4.1.1
of Part 1.

B: ED TODO: Integrate the style property changes to move the style
properties from operation to message component and add the defaulting
language for the operation component model. Part 1 and 3. changes.

I am raising an issue with respect to the second decision made by the
wg. It appears that the consequences of the decision with respect to rpc
style was not considered during the October meeting [3]. 

1) A and B are contradictory. When the style is moved to message level,
the style property can no longer contrain both input and output. It
becomes impossible to do so. So, the first ed to do A is in conflict
with the second one, B. 

2) The decision makes the rpc style completely unusable, actually
undefinable as the style is now defined for message, not for operation.
The rpc style governs the interaction and relationship between input and
output messages. Therefore, it belongs at the operation level. As a
matter of fact, moving the style attribute to message component
completely breaks the rpc style as there is no other means to relate the
constraints at the correct level of abtraction, namely the operation
that represents the interaction between input and output messages, and
the signature which is also related to it. 

This is a BIG issue and must be resolved by revisiting the decision for
LC21. I am not sure why this has been missed [3], but the attendence
list indicates that the folks who put together rpc style were not
attending. So, it is my duty to bring it to the wg's attention. :-)

The reason for moving the style to message component is to provide the
correct level of granularity for other styles to define constraints only
on the message level. However, the solution of LC21, providing correct
level of granularity should not break one of the styles we painfully
designed for a long time in this wg, namely the rpc style. 

There are several ways that this can be achieved. I looked at the
proposals that were presented during the f2f with that regard. 

-- Option 1 will not break rpc style. This will provide granularity at
both operation level and message level. 

-- Another proposal was brought up by Jonathan. To keep @style at
operation level and not introduce a message level @style. But introduce
a multi part IN and OUT style with a list of styles that produce a union
of constraints. Not clear from the minutes why this is not considered. 

Both approaches are acceptable IMO, but the second part (B) of the LC21
resolution, which is luckily not implemented yet, as stated is NOT.  We
prefer the first option, as it will allow style to appear where it
logically fits. Since composition rules for style requires all listed
styles to be observed [5], the same reasoning can apply to styles that
apply to message as well as operation to be treated as a single set. 

I propose the following 

-- we reopen the issue LC21. 
-- we keep the resolution A for LC21. 
-- we reconsider these two options instead of B which will not break rpc
style as an amendement for the resolution. 


Thanks,

--umit



[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0039.html
[2] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61a
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0042.html
[4] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC21
[5]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont
ent-type=text/html;%20charset=utf-8#InterfaceOperationStyle
----------------------

Dr. Umit Yalcinalp
NetWeaver Standards
SAP Labs, LLC
3401 Hillview Ave.
Palo Alto, CA 94304
umit.yalcinalp@sap.com
Tel: (650) 320-3095

Received on Wednesday, 22 December 2004 21:34:05 UTC