- From: Youenn Fablet <youenn.fablet@crf.canon.fr>
- Date: Mon, 29 May 2006 11:53:58 +0200
- To: Jonathan Marsh <jmarsh@microsoft.com>
- Cc: Arthur Ryman <ryman@ca.ibm.com>, Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Tony Rogers <Tony.Rogers@ca.com>, www-ws-desc@w3.org
- Message-id: <447AC4B6.90001@crf.canon.fr>
Please find in attachment, some updated results according the interchange format extensions (soap, http, safety, rpc...). I used the CVS schema version to implement the format, so there might be some differences if the schema has evolved a bit since my last CVS update. Jonathan, could you commit these documents in CVS ? Thanks, youenn Jonathan Marsh wrote: > > 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?* > > Well, conceptually each property is “namespaced” to the spec that > defines it, right? So although the parent property in part 2 is > semantically identical it seems like it’s an exact copy rather than a > full reuse. That’s a rather intellectual argument, I know. I don’t > really care too much. > > ------------------------------------------------------------------------ > > *From:* www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] > *On Behalf Of *Arthur Ryman > *Sent:* Monday, May 22, 2006 2:49 PM > *To:* Youenn Fablet > *Cc:* www-ws-desc@w3.org; www-ws-desc-request@w3.org > *Subject:* Re: WSDL 2.0 Component Model Interchange Format - HTTP > Error Code Format > > > 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 > >
Attachments
- application/x-zip-compressed attachment: cm-canonresults-3.zip
Received on Monday, 29 May 2006 09:54:31 UTC