SOAP & XSD support

This page is the operator reference for what the conversion engine handles on the SOAP side: SOAP versions, WSDL message styles, the full XSD type coverage,…

This page is the operator reference for what the conversion engine handles on the SOAP side: SOAP versions, WSDL message styles, the full XSD type coverage, faults, namespaces, nullability and empty-value semantics — and what is intentionally out of scope at v1.0.

The mapping is full-field: this coverage applies across the entire request and response tree automatically from the WSDL, not just the fields someone remembered to map. See How mapping works.

SOAP versions

Since v1.0 both SOAP versions are supported on one runtime:

SOAP 1.1 — including the faultcode / faultstring / detail fault model, the mandatory SOAPAction header, and Content-Type: text/xml.
SOAP 1.2 — including the application/soap+xml content type and the two-level fault model (Code/Value plus an application Subcode).

The runtime detects the SOAP version from the request body and content type on the wire, so you do not have to declare it manually for the conversion to work; the WSDL import also infers it from the binding.

The inbound SOAP listener used by the Consume (SOAP-facade) direction accepts SOAP 1.1 and SOAP 1.2. See Consume direction.

WSDL message styles

document/literal — both wrapped and bare.
rpc/literal — supported, including RPC-style envelope build/parse.

RPC/encoded (SOAP Section-5 encoding) is out of scope — see What's out of scope.

XSD type coverage

| Category | What's handled | |---|---| | Scalar types | string, int, long, decimal, boolean, date, dateTime, duration, base64Binary, hexBinary, and the rest of the built-in simple types | | Complex types | complexType; complexContent extension and restriction; simpleContent (scalar, and value-plus-attribute — #text + @attr) | | Composition | sequence; choice, including multi-field branches counted as one selected branch (choice groups); all | | Reuse / modularity | group and attributeGroup reference expansion; import, include, redefine (recursive, with cycle protection); external XSD resolution | | Cardinality | minOccurs / maxOccurs; arrays and repeated/wrapped elements with item-element naming | | Nullability | nillable="true" with xsi:nil round-tripping | | Attributes & mixed content | XML attributes (@attr); mixed text-plus-element content (#text) | | Substitution groups | substitutionGroup variant resolution | | Polymorphism | xsi:type discriminator variants (variantsByXsiType), with configurable handling | | Constraints / facets | enumeration, pattern (UTF-8 / Hebrew-aware regex), numeric bounds (minInclusive etc.), string-length facets | | Advanced simple types | list, union (with per-item / per-member constraint metadata) | | Wildcards | any / anyType wildcard passthrough | | Identity constraints | xsd:key, xsd:keyref, xsd:unique metadata extraction | | Multipart / external schema | multipart message parts; external schema resolution via import / include / redefine |

Each operation's parsed contract is captured as an immutable snapshot with a checksum and parser version recorded — so regeneration is deterministic and a backend WSDL change surfaces as a diff rather than a silent behavior change. See Import a WSDL.

Faults

SOAP faults are first-class, not dropped. A <soap:Fault> — SOAP 1.1 (faultcode/faultstring/detail) or SOAP 1.2 (two-level Code/Value plus Subcode) — is normalized into a deterministic REST error shape. You choose the shape with the error-shape conversion option:

the platform default error object (s2r-default),
RFC 7807 Problem Details (rfc7807),
a flat error body (flat), or
the upstream backend's error payload passed through unchanged (upstream-passthrough).

The HTTP status the failure surfaces as is governed by the upstream-failure-status option. WSDL-declared wsdl:fault detail contracts are reflected per operation in the generated OpenAPI v3 so consumers know what an error looks like before they hit one. Business-error nodes that arrive in an otherwise-successful response can also be mapped into the stable error model when configured.

Namespaces

Target namespaces, imported namespaces, and namespace URIs are preserved end-to-end.
Prefix allocation is stable and does not change the semantic namespace-URI mapping.
Namespace repair at import handles WSDLs with missing or inconsistent namespace declarations so a contract that would otherwise fail to parse can still be onboarded — repairs are surfaced in the import notes. See Import a WSDL → Namespace repair.

Nullability & empty-value semantics

The difference between "the field was absent," "the field was explicitly nil," and "the field was empty" is preserved and configurable:

xsi:nil="true" ↔ JSON null, round-tripped where the schema allows.
A non-nillable element with a null value is a request-side validation error (rather than a silently-emitted invalid envelope).
An empty element (<x/>) follows your configured null / empty handling policy for its type.
A missing optional field is omitted by default (configurable).
A nillable required field is never wrongly enforced as required on the request side.

What's out of scope

In line with the product's focus on the mainstream estate, a few SOAP-era edge cases are handled as bespoke engagements rather than in the standard v1.0 product:

RPC/encoded (SOAP Section-5 encoding) — document/literal (wrapped + bare) and rpc/literal are the supported styles.
WS-Security message signing / encryption on the inbound SOAP-facade (Consume) path — outbound REST auth (including mTLS) on the Consume side is supported; see Consume direction.
Non-HTTP transports (message queues, SFTP, etc.) — HTTP/HTTPS only.

Teams with one of these requirements are supported as a bespoke engagement. See the v1.0 release notes → out of scope.

Next reads

All Specaria SOAP to REST docs

Loading…