- From: Youenn Fablet <youenn.fablet@crf.canon.fr>
- Date: Tue, 23 May 2006 09:07:42 +0200
- To: Arthur Ryman <ryman@ca.ibm.com>
- Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
Sounds good to me. Youenn Arthur Ryman wrote: > > 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.* OK > > > 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.* Yes, this sounds cleaner to me. > > > 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?* > OK > 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.* Woups, yes, subcodes order is significant. The remark is still applicable to modules/headers. I agree they should be sorted by their uri/element QName. > > - 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 Tuesday, 23 May 2006 07:08:01 UTC