- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Mon, 22 May 2006 17:49:14 -0400
- To: Youenn Fablet <youenn.fablet@crf.canon.fr>
- Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <OF11194630.60D3CC87-ON85257176.0076E33E-85257176.0077DFFD@ca.ibm.com>
Youenn, Thx for the comments. See my replies below: 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 Youenn Fablet <youenn.fablet@crf.canon.fr> Sent by: www-ws-desc-request@w3.org 05/22/2006 10:11 AM To Arthur Ryman/Toronto/IBM@IBMCA cc www-ws-desc@w3.org Subject Re: WSDL 2.0 Component Model Interchange Format - HTTP Error Code Format Reviewing the interchange schemas for the wsdl extensions (rpc, soap...), I have some small comments: 1) why not having a wrapper element for soap/http extension components? This would allow to enforce some more constraints in the schema (like the fact that the soap version is a required property of the binding component). Sounds good to me. I'd do it for the wsdlx and wrpc extensions too. 2) In the soap cm schema, the type CodesType is a serie of 0 or more elements. The style generally used for the other interchange schemas is to have the wrapper element optional and the serie to be of 1 or more elements. It seems also that there is a lot of optionality with soap subcodes: soapFaultCode is optional and contains an optional subcodes elements that contains an optional list of code elements. Why not removing one of the element like the subcodes one ? Am I misunderstanding things here ? This confused me too. The reason is that subcodes is different than the others. The order is significant, and 0 subcodes is significant. If the element is empty then it means #any. I could make this more explicit by using a union type and introducing an <anyCode/> element. Do you prefer that. 3) the parent element is defined in several namespaces (at least the cm and soap namespaces). For instance the parent element of a soap module is in the soap namespace while the parent element of an operation component is in the cm namespace. It may be clearer to have them in the same namespace since they share the same semantics. I agree. {parent} is like a global property. So are {features} and {properties}. I was going to move then into the cmbase namespace. I didn't to avoid churn in the schema. However, I think this is a good idea. Any objection? Two small notes concerning the comparison framework: - Is it planned to add automatic ordering of the soap subcodes, soap modules and http/soap headers ? No - the order of subcodes is significant (they are a nested sequence). We are currently discussing the semantics of those others since the spec wasn't clear about their keys and uniqueness. I proposed to give them the obvious keys. They should be sorted by that key. - It seems feasible, at least with safety and rpc, to filter out these elements (on a namespace-based level) if an implementation declares that it does not support one of these features. This would allow to compare implementations with the canonical documents even if they do not fully implement all wsdl extensions. For the http/soap extensions, I am not sure of the right way to do that filtering, but it would also be nice to be able to check implementations supporting the soap binding only against wsdl documents that contain both soap and http binding (like the sparql document). The SOAP binding uses the HTTP binding. Regards, Youenn Arthur Ryman wrote: > > I modifed the schema for outputing the HTTP error code to be > consistent with the SOAP fault code change. > > Woden is about to complete support for the HTTP binding extension, at > which time, I'll update the Woden test results. > > 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 Monday, 22 May 2006 21:49:18 UTC