RE: Action 2004-11-11 check on operation@style (LC61a) (or REOPE N LC21 Resolution B)

+1 for keeping style on the operation.

I was unable to attend the F2F where this was moved, and I would have voted
strongly against it.

(Why-oh-why must we keep making this spec so "flexible" that no one will
ever use it?!)

--
Tom Jordahl
Macromedia Server Development

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Yalcinalp, Umit
> Sent: Wednesday, December 22, 2004 4:34 PM
> To: www-ws-desc@w3.org
> Subject: 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 Monday, 3 January 2005 16:32:49 UTC