- From: Jacek Kopecky <jacek.kopecky@deri.org>
- Date: Wed, 31 May 2006 17:12:02 +0200
- To: Arthur Ryman <ryman@ca.ibm.com>
- Cc: www-ws-desc@w3.org
Hi Arthur, just to recap, initially no defaults were in the component model, they were only in the syntax. This proved to be a bug for the binding defaults as the defaults may be applied to operations that don't have explicit binding operation components (e.g. in interfaceless bindings that are bound to an interface - and a set of operations - indirectly through a service and endpoint). In the interface, this is not a problem. And I would have no problem with using the style default as a shortcut in serialization - the serializer of a component model could decide to specify the default to be the most used style, so that it would shorten the resulting form. However, I can see how adding {style default} to the component model can help the readers and be more consistent on some level, so I support the proposal. Best regards, Jacek On Fri, 2006-05-19 at 17:23 -0400, Arthur Ryman wrote: > > In Part 1 the <interface> element has a styleDefault attribute but > there is no corresponding property in the component model. The > styleDefault attribute is only used to determine the {style} property > on the Interface Operation component via the XML mapping rules > > However, in Part 2 there are four default attributes and they do get > mapped to component model properties: > {soap mep default} > {http transfer coding default} > {http method default} > {http query parameter separator default} > > These default properties are matched up with corresponding non-default > properties on the component model: > {soap mep} > {http transfer coding} > {http method} > {http query parameter separator} > > The "actual" values of the property in the message are defined by the > binding rules, not the XML mapping. I find this confusing. It also has > the disadvantage that it removes the rules from the component model > so the component model builder can't evaluate them. It just copies > the XML attributes into the component model. Instead a message builder > has to have this logic. > > The Part 1 approach makes the component model simpler since the > "actual" value of the property is computed and stored in the component > model. > > However, the Part 2 approach is also good because it makes WSDL > generation simpler. For example, suppose you have the same style on > several operations. It would be simpler to specify the default in the > component model and serialize the WSDL with the style ommitted on the > operations that matched the default. > > I propose that we improve the spec by using the best aspects of Part 1 > and 2, and make them consistent. This requires the following changes: > > 1.In Part 1, add a {style default} property to the Interface > component. > 2. In Part 2, specify the rules for the properties in the XML mapping > instead of the message binding, e.g. {http method} is determined by > the actual value of the attribute if present, or the {http method > default} if present, or is GET if the operation is safe, and it POST > otherwise. This way, e.g. {http method} is the actual value used in > the message. > > Arthur Ryman, > IBM Software Group, Rational Division > > blog: http://ryman.eclipsedevelopersjournal.com/ > phone: +1-905-413-3077, TL 969-3077 > assistant: +1-905-413-2411, TL 969-2411 > fax: +1-905-413-4920, TL 969-4920 > mobile: +1-416-939-5063, text: 4169395063@fido.ca
Received on Wednesday, 31 May 2006 15:12:19 UTC