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

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