RE: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

Hi, I also like Roberto's idea, and the added description Tony suggests
would cover text about interface-less (or incomplete) bindings that we
talked about yesterday.

However, I don't think this makes sense for style default on interface
level, so I'd prefer not to make the similar (only apparently
consistent) change there.

Jacek

On Fri, 2006-06-02 at 09:52 +1000, Rogers, Tony wrote:
> 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
>  
> 
> 
> ______________________________________________________________________
> 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
> 
>

Received on Friday, 2 June 2006 09:33:13 UTC