- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Thu, 27 Feb 2003 00:07:00 +1300
- 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 attribute? 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. Pete 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