FW: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

Thank you for this comment.  The Working Group this issue as a CR044 [1].

 

We fixed it in the latest editor's draft, specifically in [2, 3].

 

Unless you let us know otherwise within 2 weeks, we will assume you agree
with the resolution of this issue.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR044

[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#Binding_details

[3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#Endpoint_details

 

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

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