- From: John Kaputin (gmail) <jakaputin@gmail.com>
- Date: Thu, 25 May 2006 01:11:13 +0100
- To: "Arthur Ryman" <ryman@ca.ibm.com>
- Cc: www-ws-desc@w3.org, woden-dev@ws.apache.org
- Message-ID: <4c2ae8f80605241711l190eb46ek5760cf249ee45b36@mail.gmail.com>
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 > > > > > > > >
Received on Tuesday, 30 May 2006 18:33:16 UTC