Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

Arthur, et. al.
I have implemented {http method} in Woden based on your proposal. i.e. the
defaulting rules for {http method}  are applied in the component model in
getHttpMethod(), not left to an external message builder to apply its own
logic to {http method}, {http method default}, then {safety}. So a message
builder can just rely on {http method} knowing that defaults based on {http
method default} or {safety} have been applied if necessary. I'll need to
know if/when the proposal this accepted to ensure compliance with the spec.
Perhaps we can discuss on the implementors call on 25th May.

John Kaputin.

On 5/24/06, John Kaputin (gmail) <jakaputin@gmail.com> wrote:
>
> Arthur,
> from a parsing perspective the Part 1 approach is simpler, where the
> default attributes don't appear as properties in the Component model but are
> just used to compute the actual values of the related properties. In Apache
> Woden we have not yet considered WSDL serialization from the Component
> model, but I think what you are proposing makes sense. If a WSDL 2.0processor is able to programmatically create the Component model or modify a
> Component model parsed from a WSDL document and then needs to serialize that
> Component model, any styleDefault attribute should be based on a {style
> default} property in the model. Otherwise, the processor has to either
> ignore the styleDefault attribute or guess it from the actual {style}
> properties.
>
> regards,
> John Kaputin.
>
>
>
> On 5/19/06, Arthur Ryman <ryman@ca.ibm.com> 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
> >
>
>