In a WSDL 1.1 SOAP binding, what do document versus rpc style and literal versus encoded use decide, and why did document/literal wrapped win?

middlemust knowfreq 28%

answer

one attribute shapes the Body, one the types
operation-named wrapper element
reader makes right versus writer makes right
one Body child, schema-declared

basics

~20 s

Style decides whether the Body holds documents or an operation-named wrapper of parameters; use decides whether a schema fixes the XML (literal) or encoding rules generate it (encoded). Document/literal wrapped won: schema-valid, cleanly dispatched, profile-conformant.

solid answer

~50 s

In WSDL 1.1, style (on soap:binding or soap:operation, default document) shapes the Body: rpc puts a wrapper element named after the operation under the Body with one accessor per part, while document puts the parts directly under the Body. use (on soap:body) is either literal, where each part points at a schema element or type and the writer must match it exactly, or encoded, where abstract types are serialized by rules such as SOAP 1.1 Section 5 encoding and the reader must accept every variation. Encoded lost on interoperability, and WS-I Basic Profile 1.1 requires literal everywhere. Document/literal wrapped is a convention, not a named style: a single part whose global element is named after the operation and contains the parameters. It looks like an RPC call on the wire, yet the whole Body child is schema-validated and identifies the operation.

In WSDL 1.1, `style` (on `soap:binding` or `soap:operation`, default `document`) shapes the Body: `rpc` puts a wrapper element named after the operation under the Body with one accessor per part, while `document` puts the parts directly under the Body. `use` (on `soap:body`) is either `literal`, where each part points at a schema element or type and the writer must match it exactly, or `encoded`, where abstract types are serialized by rules such as SOAP 1.1 Section 5 encoding and the reader must accept every variation. Encoded lost on interoperability, and WS-I Basic Profile 1.1 requires `literal` everywhere. **Document/literal wrapped** is a convention, not a named style: a single part whose global element is named after the operation and contains the parameters. It looks like an RPC call on the wire, yet the whole Body child is schema-validated and identifies the operation.

code

xml · 21 lines

xml

<!-- schema: the wrapper element is named after the operation -->
<xs:element name="GetQuote">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="symbol" type="xs:string"/>
      <xs:element name="currency" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

<!-- one part, referencing that element -->
<wsdl:message name="GetQuoteRequest">
  <wsdl:part name="parameters" element="tns:GetQuote"/>
</wsdl:message>

<!-- binding: document style, literal use -->
<wsdl:operation name="GetQuote">
  <soap:operation soapAction="http://example.com/quotes/GetQuote" style="document"/>
  <wsdl:input><soap:body use="literal"/></wsdl:input>
  <wsdl:output><soap:body use="literal"/></wsdl:output>
</wsdl:operation>

go deeper

for a junior

Recall that style is rpc or document and use is literal or encoded, and that document/literal is the form most services publish today.

for a middle

Explain how each style arranges the Body, reader-makes-right against writer-makes-right, and the three conventions that make document/literal wrapped.

for a senior

Trace an interop failure to its binding: encoded arrays, a bare multi-part document binding, or duplicate operation signatures that break dispatch, and fix each against the profile.

for a principal

Set a house rule for SOAP contracts: wrapped for operation-style services, bare document/literal for industry documents, and how you enforce profile conformance in review.

Two attributes, two separate questions

A WSDL 1.1 SOAP binding answers two questions about every message, with two attributes:

style, on soap:binding (the default for all operations) or on soap:operation (per operation), takes rpc or document. If neither says, it is document. It decides the shape of the Body: a call with parameters, or one or more documents.
use, on soap:body, soap:header and soap:fault, takes literal or encoded and is required. It decides who defines the XML: a schema the writer must match exactly (literal), or abstract types turned into XML by an encoding named in encodingStyle (encoded).

The WSDL 1.1 Note gives the two attitudes names. With an encoding that allows variations, "it is up to the reader of the message to understand all the format variations: 'reader makes right'". With a concrete schema, "the writer of the message must conform exactly to the specified schema: 'writer makes right'".

What rpc and document style do to the Body

WSDL 1.1 section 3.5 is precise:

rpc: each part is a parameter or return value inside "a wrapper element within the body". The wrapper "is named identically to the operation name", its namespace is the namespace attribute of soap:body, and each part becomes an accessor named after the parameter, in call order.
document: "there are no additional wrappers, and the message parts appear directly under the SOAP Body element."

Combination	Body content	WS-I Basic Profile 1.1
rpc/encoded	operation wrapper, SOAP-encoded parameters	prohibited
rpc/literal	operation wrapper, parts typed by schema types	allowed
document/encoded	parts under Body, SOAP-encoded	prohibited
document/literal	schema elements under Body, at most one part	allowed

Under the profile an rpc-literal response wrapper is named after the operation with Response appended, and rpc-literal parts must use the type attribute, while document-literal parts must use element.

Why encoded lost

SOAP 1.1 Section 5 encoding has its own data model. Values shared by several accessors are multi-reference: serialized once with an id attribute and pointed at with href. Arrays carry a SOAP-ENC:arrayType attribute, and values often carry xsi:type. The same graph can be written several ways, and every reader must accept all of them.

Toolkits disagreed on arrays, multi-reference values and type annotations, so two conformant stacks could fail to exchange the same call.
An encoded Body cannot simply be validated against an XML Schema, because the schema does not describe the wire form.
The data model maps programming-language object graphs, which ties the contract to a language view rather than to a document.

WS-I Basic Profile 1.1 settled it: R2706 says a binding "MUST use the value of 'literal'" in every soapbind:body, soapbind:fault, soapbind:header and soapbind:headerfault. SOAP 1.2 Part 2 then made its data model, encoding and RPC representation OPTIONAL for implementations.

Document/literal wrapped

Neither WSDL 1.1 nor the Basic Profile names "wrapped"; it is a convention layered on document/literal, adopted widely because it gives the best of both shapes:

The input message has exactly one part, declared with element.
That global element is named after the operation; the output message's element follows a matching convention, commonly the operation name plus Response.
The element's type is a sequence of the parameters; the response element holds the return value.

On the wire this looks like rpc/literal: an operation-named element directly under the Body. The difference is that the element is declared in the schema, so the whole Body child validates.

Why wrapped won

Schema validation: the Body child is one schema-declared element, so standard XML Schema tools check the entire payload.
Profile conformance: a single element part satisfies R2201 (at most one part) and R2204 (element-defined parts).
Clean dispatch: the profile's operation signature is the qualified name of the Body's child; R2710 requires it to differ per operation, and an operation-named wrapper makes that automatic, with no reliance on SOAPAction.
Familiar programming model: generators can unwrap the children into method parameters, so callers still see a call signature.

The costs are modest: the operation name is baked into a schema element, reusing one element as input to two operations breaks signature uniqueness, and the payload is still verbose XML. Bare document/literal, where a part references any business document, remains valid and suits genuine document exchange; it simply leaves dispatch and naming to the designer.

## Two attributes, two separate questions A WSDL 1.1 SOAP binding answers two questions about every message, with two attributes: - **`style`**, on `soap:binding` (the default for all operations) or on `soap:operation` (per operation), takes `rpc` or `document`. If neither says, it is `document`. It decides the **shape of the Body**: a call with parameters, or one or more documents. - **`use`**, on `soap:body`, `soap:header` and `soap:fault`, takes `literal` or `encoded` and is required. It decides **who defines the XML**: a schema the writer must match exactly (`literal`), or abstract types turned into XML by an encoding named in `encodingStyle` (`encoded`). The WSDL 1.1 Note gives the two attitudes names. With an encoding that allows variations, "it is up to the reader of the message to understand all the format variations: 'reader makes right'". With a concrete schema, "the writer of the message must conform exactly to the specified schema: 'writer makes right'". ## What rpc and document style do to the Body WSDL 1.1 section 3.5 is precise: - **rpc:** each part is a parameter or return value inside "a wrapper element within the body". The wrapper "is named identically to the operation name", its namespace is the `namespace` attribute of `soap:body`, and each part becomes an accessor named after the parameter, in call order. - **document:** "there are no additional wrappers, and the message parts appear directly under the SOAP Body element." | Combination | Body content | WS-I Basic Profile 1.1 | |---|---|---| | rpc/encoded | operation wrapper, SOAP-encoded parameters | prohibited | | rpc/literal | operation wrapper, parts typed by schema types | allowed | | document/encoded | parts under Body, SOAP-encoded | prohibited | | document/literal | schema elements under Body, at most one part | allowed | Under the profile an rpc-literal response wrapper is named after the operation with `Response` appended, and rpc-literal parts must use the `type` attribute, while document-literal parts must use `element`. ## Why encoded lost SOAP 1.1 Section 5 encoding has its own data model. Values shared by several accessors are **multi-reference**: serialized once with an `id` attribute and pointed at with `href`. Arrays carry a `SOAP-ENC:arrayType` attribute, and values often carry `xsi:type`. The same graph can be written several ways, and every reader must accept all of them. 1. Toolkits disagreed on arrays, multi-reference values and type annotations, so two conformant stacks could fail to exchange the same call. 2. An encoded Body cannot simply be validated against an XML Schema, because the schema does not describe the wire form. 3. The data model maps programming-language object graphs, which ties the contract to a language view rather than to a document. WS-I Basic Profile 1.1 settled it: R2706 says a binding "MUST use the value of 'literal'" in every `soapbind:body`, `soapbind:fault`, `soapbind:header` and `soapbind:headerfault`. SOAP 1.2 Part 2 then made its data model, encoding and RPC representation **OPTIONAL** for implementations. ## Document/literal wrapped Neither WSDL 1.1 nor the Basic Profile names "wrapped"; it is a convention layered on document/literal, adopted widely because it gives the best of both shapes: 1. The input message has exactly **one part**, declared with `element`. 2. That global element is **named after the operation**; the output message's element follows a matching convention, commonly the operation name plus `Response`. 3. The element's type is a sequence of the **parameters**; the response element holds the return value. On the wire this looks like rpc/literal: an operation-named element directly under the Body. The difference is that the element is declared in the schema, so the whole Body child validates. ## Why wrapped won - **Schema validation:** the Body child is one schema-declared element, so standard XML Schema tools check the entire payload. - **Profile conformance:** a single `element` part satisfies R2201 (at most one part) and R2204 (`element`-defined parts). - **Clean dispatch:** the profile's **operation signature** is the qualified name of the Body's child; R2710 requires it to differ per operation, and an operation-named wrapper makes that automatic, with no reliance on `SOAPAction`. - **Familiar programming model:** generators can unwrap the children into method parameters, so callers still see a call signature. The costs are modest: the operation name is baked into a schema element, reusing one element as input to two operations breaks signature uniqueness, and the payload is still verbose XML. Bare document/literal, where a part references any business document, remains valid and suits genuine document exchange; it simply leaves dispatch and naming to the designer.

On the wire, how do you tell rpc/literal from document/literal wrapped?
Often you cannot: both put an operation-named element under the Body. The difference is in the description. In rpc/literal the wrapper is synthesized from the operation name and the `namespace` attribute, and parts reference types; in wrapped, the wrapper is a global schema element referenced by a single `element` part, so the whole Body child validates.
Why does WS-I Basic Profile 1.1 care that operation signatures differ?
Because an endpoint must work out which operation was invoked from the input message. The profile defines the signature as the qualified name of the Body's child and R2710 requires every operation in a binding to produce a different one. Bare document/literal with a shared element breaks that; wrapped satisfies it by naming the element after the operation.
When is bare document/literal, without the wrapper convention, the better choice?
When the message really is a business document, such as an invoice or a claim defined by an industry schema, and you want that document under the Body unchanged. You then keep one element per operation, or make dispatch explicit, so operation signatures stay unique.

saying these in an interview costs you the question

Wrapped is a third value of the WSDL 1.1 style attribute.
rpc style means SOAP encoding; the two cannot be separated.
WS-I Basic Profile 1.1 forbids rpc style entirely.
Encoded use is fine because every toolkit implements SOAP encoding identically.
Document style always means a SOAP message carries several business documents.

In a WSDL 1.1 SOAP binding, what do document versus rpc style and literal versus encoded use decide, and why did document/literal wrapped win?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two attributes, two separate questions

What rpc and document style do to the Body

Why encoded lost

Document/literal wrapped

Why wrapped won

▾common follow-ups3 questions

▾red flags5 flags

Two attributes, two separate questions

What rpc and document style do to the Body

Why encoded lost

Document/literal wrapped

Why wrapped won

answer

go deeper