Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

Jacek,

Thx for reminding me about the interface-less binding requirement. I can 
see that the situations and not completely analogous.

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



Jacek Kopecky <jacek.kopecky@deri.org> 
Sent by: www-ws-desc-request@w3.org
05/31/2006 11:12 AM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother







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