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