Re: Parts 1 and 2 Treat Defaults Inconsistently with Eachother

Arthur wrote>
2. In Part 2, specify the rules for the properties in the XML mapping
instead of the message binding, e.g. {http method} is 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.

And if applying these default rules in the Component model,  the {http
method} property should probably be changed to REQUIRED instead of OPTIONAL..


regards,
John Kaputin.


On 5/25/06, John Kaputin (gmail) <jakaputin@gmail.com> wrote:
>
> 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
> > >
> >
> >
>