- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Mon, 29 May 2006 14:26:25 -0400
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <OF762D66C7.A8E56C1C-ON8525717D.0064F651-8525717D.00655258@ca.ibm.com>
Jonathan, Jacek and I agree that we should keep the default properties in the component model. Note that I proposed we add {style default}. The general pattern should be that: 1) the component model includes defaults at a higher scope than the property they default for (e.g. a parent provides a default for a child) 2) the actual value of the property is computed in the component model, not left to the concrete binding 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 "Jonathan Marsh" <jmarsh@microsoft.com> Sent by: www-ws-desc-request@w3.org 05/25/2006 10:35 AM To Arthur Ryman/Toronto/IBM@IBMCA, <www-ws-desc@w3.org> cc Subject RE: Parts 1 and 2 Treat Defaults Inconsistently with Eachother Recall that Jacek raised an issue [1] against computing the actual values (and omitting the *-default properties from the component model.) The requirements for defaults in the SOAP binding and for defaults in part 1 are somewhat different. [1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC333 From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Arthur Ryman Sent: Friday, May 19, 2006 2:23 PM To: www-ws-desc@w3.org Subject: Parts 1 and 2 Treat Defaults Inconsistently with Eachother 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 Monday, 29 May 2006 18:26:33 UTC