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

Done.  Results look great!

I used your sparql results as the baseline since they appear to be much
closer than the other implementations.  Otherwise the "failures" seem
mostly like nits.  You seem to be emitting a safety="false" when the
wsdl says safety="true".  You also seem to be missing a style <uri>.
You, Woden, and I all seem to disagree in the GreatH cases precisely
which soap binding properties are required to appear - I think we've got
issues open on this topic.

> -----Original Message-----
> From: Youenn Fablet [mailto:youenn.fablet@crf.canon.fr]
> Sent: Monday, May 29, 2006 2:54 AM
> To: Jonathan Marsh
> Cc: Arthur Ryman; Jean-Jacques Moreau; Tony Rogers; www-ws-desc@w3.org
> Subject: 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
> >
> >
>

Received on Monday, 29 May 2006 15:13:26 UTC