- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 29 May 2006 08:13:00 -0700
- To: "Youenn Fablet" <youenn.fablet@crf.canon.fr>
- 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>
Done. Results look great! I used your sparql results as the baseline since they appear to be much closer than the other implementations. Otherwise the "failures" seem mostly like nits. You seem to be emitting a safety="false" when the wsdl says safety="true". You also seem to be missing a style <uri>. You, Woden, and I all seem to disagree in the GreatH cases precisely which soap binding properties are required to appear - I think we've got issues open on this topic. > -----Original Message----- > From: Youenn Fablet [mailto:youenn.fablet@crf.canon.fr] > Sent: Monday, May 29, 2006 2:54 AM > To: Jonathan Marsh > Cc: Arthur Ryman; Jean-Jacques Moreau; Tony Rogers; www-ws-desc@w3.org > Subject: Re: WSDL 2.0 Component Model Interchange Format - HTTP Error Code > Format > > 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 > > > > >
Received on Monday, 29 May 2006 15:13:26 UTC