James, You are correct -- neither the WSDL 1.1 spec nor the SOAP 1.1 spec specifies that the <soap:Body> may contain at most one top-level element, but neither do they specify how a SOAP engine should interpret a <soap:Body> that contains more than one top-level element.
Should the extra elements be treated as multiple elements for input to a single operation, or should each element be processed as a separate operation request? Most SOAP engines, including Axis, ignore all extra elements. I'm surprised to hear you say that you have produced a doc/lit service with mutliple body parts that worked the way you expected it to. I've answered quite a few questions on this list from people who say that they're missing all by the first parameter when using doc/lit. The "one top-level element per <soap:Body>" rule comes from the WS-I BP. (Also note that WSDL 1.1 is not a W3C Recommendation. It's just a "W3C Note". That status does not imply any kind of endorsement or ratification by W3C. It just means that W3C has published a submitted specification for the purpose of public discussion.) Anne On 7/26/05, James Wilson <[EMAIL PROTECTED]> wrote: > > > Quoting Anne Thomas Manes <[EMAIL PROTECTED]>: > > > WSDL style (rpc vs document) has no impact on whether or not you can > > map multiple binding ports to a single URL. That's more likely to be a > > function of your SOAP engine rather than the design of your service. > > > > There are a number of differences between the way you define an > > rpc/lit WSDL versus a doc/lit WSDL, but "wrapped" doc/lit and rpc/lit > > look almost identical on the wire. You may see differences in > > namespaces and in the response element name. In doc/lit, the schema > > explicitly specifies the name of the response element and what > > namespaces must be used for the top-level element and all local > > elements. In rpc/lit, the top-level element within the <soap:Body> is > > in the namespace specified by the namespace attribute in the > > <wsdlsoap:body> definition in the <wsdl:binding>, and the parameter > > elements are never namespace qualified. Also, in rpc/lit the SOAP > > engine autogenerates the name of the response element, and its name is > > not significant. > > > > When using doc/lit, you define the full schema of the message payload > > by defining the <xsd:element> structure of the contents of the > > <soap:Body>. There can be at most one top-level element within the > > <soap:Body>, therefore this element must contain all message > > parameters. > > I'm confused by this last sentence. I don't see in the WSDL1.1 spec from w3c > that a doc/lit body can have only one child element, "If the operation style > is > document there are no additional wrappers, and the message parts appear > directly > under the SOAP Body element." In practice, my services that had more than one > part, produced messages that had more than one child element in the > soapenv:body. > > I did encounter that the WS-I Basic Profile adds the restriction that doc/lit > messages can have only one part. > > > The <wsdl:message> definition must specify at most one > > body part (although it may contain additional header or fault parts), > > and that body part must reference the <xsd:element> definition. For > > example, for an operation "foobar" with two input parameters "foo" and > > "bar", the <wsdl:message> definition would look like this: > > > > <wsdl:message name="foobarRequest"> > > <wsdl:part name="body" element="ns1:foobar"/> > > </wsdl:message> > > > > And the ns1:foobar element definition would look something like this: > > > > <xsd:element name="foobar"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element name="foo" type="xsd:string"/> > > <xsd:element name="bar" type="xsd:string"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > > > When using wrapped doc/lit, the top-level element name must be the > > same as the operation name (in this case, "foobar"). When using > > unwrapped doc/lit, the top-level element may have any name -- but you > > still must define all input information as local elements within the > > top-level element. > > > > When using rpc/lit, you do not define the full schema of the message > > payload. Instead you only define the types of your input parameters. > > At runtime, the SOAP engine autogenerates the message element > > structure. As with doc/lit, the <soap:Body> may contain at most one > > top-level element, but in this case, the SOAP engine generates this > > element. It uses the operation name for the element's local name, and > > it gets the namespace from the namespace attribute in the > > <wsdlsoap:body> definition. The SOAP engine also generates elements > > for each parameter type. These elements as unqualified, and the local > > name comes from the name attribute in the <wsdl:part> definition. > > > > In rpc/lit, the <wsdl:message> definition specifies one body part for > > each operation parameter. Each <wsd:part> definition must specify the > > name of the parameter and the parameter type. If the parameter type is > > a complexType, then the type must be defined as a <xsd:complexType> in > > the <wsdl:types> section. For the "foobar" example, the <wsdl:message> > > definition would look like this: > > > > <wsdl:message name="foobarRequest"> > > <wsdl:part name="foo" type="xsd:string"/> > > <wsdl:part name="bar" type="xsd:string"/> > > </wsdl:message> > > > > Anne > > > > On 7/26/05, Mark Hansen <[EMAIL PROTECTED]> wrote: > > > Is the only difference between rpc/lit and doc/lit that the rpc/lit > > > style wraps the parameters (parts) in the method (operation) name? Is > > > the purpose of the rpc/lit style to use the method wrapper as a way to > > > implement the WSDL allowed mapping of multiple binding ports to a single > > > URL? > > > > > > Thanks for any clarification, > > > > > > Mark > > > > > > > > >
