RE: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

I think that Roberto's idea is good, provided we modify the text to
explain that the {soap mep} at the binding level exists solely to
provide a default for {soap mep} at the binding operation level. Without
that kind of text, I feel it would introduce more confusion, rather than
alleviate confusion in the way we hope. I don't want anyone arguing:
"oh, but it's obvious!" :-)
 
I'm happy to see styledefault go the same way, but with the same proviso
- we must state explicitly in the text that it is applied at the higher
level to give a default to the lower level. If people aren't happy with
adding that kind of text, then I'd be opposed to making the change.
 
With the text about defaulting, I think this would be a change that
could be argued not to change a reader's "experience of the spec".
 
Tony Rogers
tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com> 
 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Friday, 2 June 2006 8:00
To: Roberto Chinnici
Cc: Jacek Kopecky; www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother



Roberto, 

Dropping the {... default} suffix is interesting. This is like the
scoping rules for F & P. 

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 



Roberto Chinnici <Roberto.Chinnici@Sun.COM> 
Sent by: www-ws-desc-request@w3.org 

05/31/2006 01:34 PM 

To
Jacek Kopecky <jacek.kopecky@deri.org> 
cc
Arthur Ryman/Toronto/IBM@IBMCA, www-ws-desc@w3.org 
Subject
Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

	





Jacek explained nicely why there is no {style default} property.
Since there is no need for it, I'm against adding one just for the sake
of having the component model mimic the overt syntax.

He also explained why we do have rules in part 2 that are applied
when the binding is used, rather than at component model construction
time: not all operations in an interface need to be bound. It seems
pointless then to force those properties to appear when a binding
operation is present, since that won't result in any simplification
of the rules in the spec.

Perhaps the reason for the {... default} properties in part 2 would
become clearer if we renamed them by dropping the " default" suffix.
Then we'd have e.g. a {soap mep} property at the binding level and
a {soap mep} at the binding operation level, and the rules would
look like plain old overriding rather than applying a default.

Thanks,
Roberto

Jacek Kopecky wrote:
> 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