W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2003

Re: WSDL 1.2 drops use="encoded"

From: Pete Hendry <peter.hendry@capeclear.com>
Date: Thu, 27 Feb 2003 00:07:00 +1300
Message-ID: <3E5C9FD4.2010902@capeclear.com>
To: Rich Salz <rsalz@datapower.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>

My understanding of this proposal is that for all cases the schema 
generated must be correct to match the message content. This means that 
anything that can be a multiref must have id/ref attributes defined in 
its schema definition. This is so the message matches "literal". 
However, encodingStyle="...soapenc1.2..." indicates that the 
soapencoding 1.2 rules (or 1.1) should be applied, which is basically 
the extra layer of interpretation above the schema definition such as 
what a multiref is.

This is a lot tighter than the current spec where the schema is more of 
an abstract definition of types when use="encoded", usually not 
including ref/id attributes or minOccurs="0" in complex types, and the 
prose definition of the encoding takes precedence over the schema. The 
onus then moves to the WSDL generation tools to be much more precise in 
what they generate. Is this correct?

What about soapenc 1.1 arrays? Or does WSDL 1.2 no longer support 
soapenc 1.1? Is there not a problem "literal"ly defining arrays in 
soapenc 1.1 because there is no way to have a default value for a QName 

What I'm not sure of is the benefit of this. Because of the use of 
style="rpc" the document/message can't be validated against the schema 
anyway. The wrapper element which is the RPC element in the call is not 
described in the schema but only in the WSDL and so a schema parser may 
not be able to validate the message in the rpc case.


Rich Salz wrote:

>Just to make sure I understand, is the following statement accurate:
>   WSDL 1.2 cannot describe SOAP 1.1 "section 5" messages
>   (and therefore presumably "RPC encoding" of SOAP 1.2)
Received on Wednesday, 26 February 2003 06:07:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:22 UTC