- From: John Kaputin (gmail) <jakaputin@gmail.com>
- Date: Thu, 25 May 2006 00:04:28 +0100
- To: "Arthur Ryman" <ryman@ca.ibm.com>
- Cc: www-ws-desc@w3.org, woden-dev@ws.apache.org
- Message-ID: <4c2ae8f80605241604n6f832a7g73c0cf8d0a534da1@mail.gmail.com>
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:12 UTC