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
>
>