W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2006

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

From: Youenn Fablet <youenn.fablet@crf.canon.fr>
Date: Tue, 30 May 2006 11:20:12 +0200
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: Arthur Ryman <ryman@ca.ibm.com>, Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Tony Rogers <Tony.Rogers@ca.com>, www-ws-desc@w3.org
Message-id: <447C0E4C.7090304@crf.canon.fr>

Jonathan Marsh wrote:
> Style uri appears missing from 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results/Canon/GreatH-3G/primer-hotelReservationService-results.xml 
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/test-suite/results/Canon/GreatH-3G/primer-hotelReservationService-results.xml>
I finally caught the bug. I misread the interchange schema and was 
generating a sequence of style elements, while I should have generated a 
single style element with a sequence of uri elements in it.
Interestingly, it seems the canonicalization stylesheet is removing the 
style element text node that was present in the non-canonical 
interchange dump.
Please find in attachment some new results with safety and style bugs 
hopefully fixed. I also added the subFaultCodes element even if no sub 
code is given.
> As I read the spec the (for instance) {soap version} property is 
> required. Since the SOAP binding itself is clearly optional, the 
> cmsoap:soapVersion element needs ultimately to be optional. It MUST be 
> present when wsdl:binding type=”http://www.w3.org/@@@@/@@/wsdl/soap” 
> is present.
Yes, that is how I interpret it. The wrapper element would mimic nicely 
this behaviour.
There might be a similar issue with the required http properties brought 
by the soap binding.
The cookies property for instance is required if the http binding is 
Its requiredness in the case of a soap over http binding is not clear to 
me when reading the specification (beginning of section 5).
> I suppose a wrapper element might help a little, but all it does is 
> make a component model error surface as a validation error. But it’s 
> still an error!
I thought the confusion was due to the interchange format itself which 
except from its schema has no real documentation.
That is why the more knowledge we put in the schema, the less confusion 
we will have at the interchange level.
The specification itself is clear to me with that respect but I may be 
biaised and if there is a way to improve it further, I am all for it.


Received on Tuesday, 30 May 2006 09:20:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:59 UTC