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

Dear All
Is there any paper that explains the latest development on WSDL 2.x. I
have been searching for such a paper but I could not get a comprehensive
one that describes the latest development on WSDL.

Appreciate your help on this

Regards,
MAQBOOL 

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Youenn Fablet
Sent: Tuesday, May 23, 2006 11:08 AM
To: Arthur Ryman
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


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:22:34 UTC