W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2006

Re: WSDL 2.0 Component Model Interchange Format - HTTP Error Code Format

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
Message-id: <4472B4BE.3090001@crf.canon.fr>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:40 GMT