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