SOAP::...::WS_I(3pm)

📦
version 3.004 · 7 versions
, in ubuntu noble, ubuntu resolute, ubuntu stonking

🎀 NAME 🎀

bestie, welcome to SOAP::...::WS_I(3pm) — straight out of User Contributed Perl Documentation. Its full government name is SOAP::WSDL::Manual::WS_I, and it's literally the whole "how does SOAP::WSDL comply with WS-I Basic Profile 1.0" story. 💅

✨ DESCRIPTION ✨

okay so this doc is the vibe check on how SOAP::WSDL confirms to the rules of the WS-I Basic Profile 1.0, which lives at http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html 🦋

Errata are not yet worked in.

Also, real talk: you may find rules mis-categorized, especially in the "not applicable" section.

Those mis-categorizations are documentation bugs, so please feel free to report them. 🙈

Rules are categorized into the following sections:

  • RULES CONFIRMED — this section contains rules SOAP::WSDL follows. Conformance to these rules may be assured by a test.
  • RULES NOT CONFIRMED — this section contains rules SOAP::WSDL does not follow yet. These may be considered as bugs. 😭
  • RULES NOT APPLICABLE — WS-I Basic Profile contains rules for web services as a whole. SOAP::WSDL only plays the part of one layer in a Web Service CONSUMER / RECEIVER, thus does not implement some parts the WS-I Basic Profile references. This section contains rules not applicable for SOAP::WSDL, because they refer to parts SOAP::WSDL does not implement.

👑 RULES CONFIRMED 👑

she's compliant, she's iconic, let's go rule by rule 💖

R1005

A MESSAGE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/envelope/".

SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle attributes on any element. periodt ✨

R1006

A MESSAGE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.

SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle attributes on any element. (same energy, different rule 🫶)

R1008

A MESSAGE MUST NOT contain a Document Type Declaration.

SOAP::WSDL::Serializer::SOAP11 does not add DTDs. no DTDs in this group chat 🚫

R1009

A MESSAGE MUST NOT contain Processing Instructions.

SOAP::WSDL::Serializer::SOAP11 does not add Processing Instructions.

R1010

A RECEIVER MUST accept messages that contain an XML Declaration.

SOAP::WSDL::Expat::MessageParser allows the use of XML Declarations. 💜

R1011

A MESSAGE MUST NOT have any element children of soap:Envelope following the soap:Body element.

SOAP::WSDL::Serializer::SOAP11 does not emit children of soap:Envelope following the soap:Body element. Other serializers may behave different. 👀

R1012

A MESSAGE MUST be serialized as either UTF-8 or UTF-16.

SOAP::WSDL::Serializer::SOAP11 serializes messages as UTF-8.

R1018

The media type of a MESSAGE's envelope MUST indicate the correct character encoding, using the charset parameter.

SOAP::WSDL::Transport::HTTP sets the Content-type header to text/xml; charset=utf8. SOAP::Transport does, too. Other transport backends may behave different. 🌈

R1014

The children of the soap:Body element in a MESSAGE MUST be namespace qualified.

SOAP::WSDL::Serializer::SOAP11 emits namespace-qualified child elements of the soap:Body element. slay 💅

R1017

A RECEIVER MUST NOT mandate the use of the xsi:type attribute in messages except as required in order to indicate a derived type (see XML Schema Part 1: Structures, Section 2.6.1).

SOAP::WSDL::Expat::MessageParser does not require the use of xsi:type attributes, but uses typemaps instead.

Other deserializers may not comply to this rule. 🙃

R1028

When a Fault is generated by a RECEIVER, further processing SHOULD NOT be performed on the SOAP message aside from that which is necessary to rollback, or compensate for, any effects of processing the message prior to the generation of the Fault.

A fault is generated when an error occurs processing the message. SOAP::WSDL::Deserializer::SOAP11 does not perform any additional processing after an error occurred. we stop right there, no cap ✋

R1029

Where the normal outcome of processing a SOAP message would have resulted in the transmission of a SOAP response, but rather a SOAP Fault is generated instead, a RECEIVER MUST transmit a SOAP Fault message in place of the response.

A fault is generated when an error occurs processing the message. 🔥

R1030

A RECEIVER that generates a SOAP Fault SHOULD notify the end user that a SOAP Fault has been generated when practical, by whatever means is deemed appropriate to the circumstance.

Via return value. short king of a rule 💖

R1140

A MESSAGE SHOULD be sent using HTTP/1.1.

SOAP::WSDL::Transport::HTTP uses HTTP/1.1. ⭐

R1141

A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0.

SOAP::WSDL::Transport::HTTP uses HTTP/1.1. yes bestie, again 💅

R1107

A RECEIVER MUST interpret SOAP messages containing only a soap:Fault element as a Fault.

SOAP::WSDL::Deserializer::SOAP11 does this. ✨

R1132

A HTTP request MESSAGE MUST use the HTTP POST method.

Both SOAP::WSDL::Transport::HTTP and SOAP::Transport::HTTP use POST. 🫶

R1108

A MESSAGE MUST NOT use the HTTP Extension Framework (RFC2774).

SOAP::WSDL::Transport::HTTP does not use the HTTP Extension framework, however SOAP::Transport::HTTP use M-POST if POST was not successful. 😬

To be sure you comply to this rule, use SOAP::WSDL::Transport::HTTP as transport backend. like, do that 👑

R1109

The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.

SOAP::WSDL::Client always quotes the SOAPAction header. those quotes are iconic and non-negotiable 🎀

R1119

A RECEIVER MAY respond with a Fault if the value of the SOAPAction HTTP header field is not quoted.

SOAP::WSDL does not apply any processing on the SOAPAction header field.

R1131

A CONSUMER MAY automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response.

LWP::UserAgent (used by SOAP::WSDL::Transport::HTTP and SOAP::Transport::HTTP) accepts up to 7 levels of redirect by default. seven! the way that's a whole number 🔥

R2113

A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute.

SOAP::WSDL does not natively support soapenc::arrayType. 💀

R2114

The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same.

SOAP::WSDL does not impose any constraints on the target namespace for WSDL definitions or schema definitions. live your truth, namespaces 🌸

R2301

The order of the elements in the soap:body of a MESSAGE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it.

SOAP::WSDL obeys the part order. in order, always 💅

R2712

A document-literal binding MUST be represented on the wire as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part.

If defined accordingly in the DESCRIPTION, SOAP::WSDL issues document-literal binding operation MESSAGES conforming to this rule. 🌈

R2748

A CONSUMER MUST NOT interpret the presence of the wsdl:required attribute on a soapbind extension element with a value of "false" to mean the extension element is optional in the messages generated from the WSDL description.

SOAP::WSDL does not interpret the wsdl:required attribute at all. not even a little 🫶

R5000

An INSTANCE MAY require the use of HTTPS.

SOAP::WSDL supports https. 🔒✨

R5010

An INSTANCE MAY require the use of HTTPS with mutual authentication.

SOAP::WSDL supports all kinds of authentication known to LWP::UserAgent. all of them, she's flexible like that 👑

R2742

A MESSAGE MAY contain a fault detail entry in a SOAP fault that is not described by a wsdl:fault element in the corresponding WSDL description.

SOAP::WSDL does not emit such faults. Such faults can be processed by adding custom maps to the type maps for SOAP::WSDL::Expat::MessageParser. iykyk 🧚

R2744

A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description.

SOAP::WSDL uses the soapAction attribute from soapbind:operation as SOAPAction header in generated code.

Alternative WSDL parsers / code generator have to assure they pass the correct soap_action to SOAP::WSDL::Client.

The interpreting SOAP::WSDL client does not conform to this rule, but "guesses" the SOAPAction header from the operation name and the top node's namespace. lowkey chaotic but that's the truth 🙈

R2745

A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted empty string value, if in the corresponding WSDL description, the soapAction of soapbind:operation is either not present, or present with an empty string as its value.

SOAP::WSDL::Client always assures the SOAPaction header is quoted, thus automatically inserts the empty string if no SOAPAction header is defined. 💖

R1015

A RECEIVER MUST generate a fault if they encounter a message whose document element has a local name of "Envelope" but a namespace name that is not "http://schemas.xmlsoap.org/soap/envelope/".

SOAP::WSDL::Expat::MessageParser checks the namespace of the SOAP envelope.

SOAP::WSDL::Expat::MessageParser does not check that Envelope is the root element, yet. 👀

R1110

An INSTANCE MAY accept connections on TCP port 80 (HTTP)

SOAP::WSDL::Server::CGI may be used in a web server listening at port 80. 🍓

R1124

An INSTANCE MUST use a 2xx HTTP status code for responses that indicate a successful outcome of a request.

SOAP::WSDL::Server::CGI sends a 2xx HTTP status code for successful requests. 🎀

R1111

An INSTANCE SHOULD use a "200 OK" HTTP status code for responses that contain a SOAP message that is not a SOAP fault.

SOAP::WSDL::Server::CGI does this. ✨

R1112

An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response that does do not contain a SOAP message but indicates successful HTTP outcome of a request.

SOAP::WSDL::Server::CGI does this. 🫶

R1130

An INSTANCE MUST use HTTP status code "307 Temporary Redirect" when redirecting a request to a different endpoint.

SOAP::WSDL::Server::CGI has no means of redirecting. The web server running a SOAP::WSDL::Server::CGI script is responsible for redirecting with a 307 HTTP status code. not her job bestie 💅

R1125

An INSTANCE MUST use a 4xx HTTP status code for responses that indicate a problem with the format of the request.

SOAP::WSDL does this. 🌈

R1113

An INSTANCE SHOULD use a "400 Bad Request "HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

SOAP::WSDL does this. 💜

R1114

An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST".

SOAP::WSDL does this. 🔥

R1115

An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if the Content-Type HTTP request header did not have a value consistent with the value specified for the corresponding binding of the input message.

SOAP::WSDL::Server::CGI does not support any content type other than text/xml and application/xml yet. 😭

💖 RULES NOT CONFIRMED 💖

Okay bestie, these are the rules that are not fully confirmed yet. Some are partially there, some are straight-up TODO. Buckle up, we're going rule by rule. ✨

R4001 🎀

A RECEIVER MUST accept messages that include the Unicode Byte Order Mark (BOM). 💅

May automatically work with XML::Parser::Expat, but is not tested yet.

TODO: write test. If not confirmed, add encoding support. 😭

R1002 🌸

A RECEIVER MUST accept fault messages that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified.

Partially confirmed: This only works when the fault detail elements are added to the deserializer's typemap.

TODO: add processing of arbitrary content of faults to SOAP::WSDL::Expat::MessageParser.

R1003 🦋

A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than http://schemas.xmlsoap.org/soap/envelope/.

TODO: add processing of arbitrary attributes to SOAP::WSDL::SOAP::Typelib::Fault11.

R1016 💜

A RECEIVER MUST accept fault messages that carry an xml:lang attribute on the faultstring element.

SOAP::WSDL::Expat::MessageParser currently ignores all attributes.

TODO: add processing of the xml:lang attribute to SOAP::WSDL::SOAP::Typelib::Fault11.

R1007 🔥

A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements are grandchildren of soap:Body.

SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle attributes on any element.

However, rpc-literal bindings are not supported, yet.

TODO: support rpc-literal bindings.

R2008 ✨

In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint.

The wsdl:import element imports the referenced WSDL definition.

This is rather hard-wired and does not allow one to specify a wsdl:import without a resolvable location in SOAP::WSDL.

R4002 🌈

A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).

TODO: Test.

R4003 ⭐

A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.

TODO: Test whether UTF-16 works.

R2020 🎀

The wsdl:documentation element MAY occur as a child of the wsdl:import element in a DESCRIPTION.

Not tested yet.

R2024 🦋

The wsdl:documentation element MAY occur as a first child of the wsdl:definitions element in a DESCRIPTION.

TODO: Test.

R2027 💅

If during the processing of an element in the WSDL namespace in a description, a consumer encounters a WSDL extension element amongst its element children, that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing of that element in the WSDL namespace.

TODO: Implement support for wsdl:required.

R2750 👑

A CONSUMER MUST ignore a SOAP response carried in a response from a one-way operation.

SOAP::WSDL does not ignore the SOAP response from a one way operation yet.

TODO: Define operation type signature, and ignore result from one way operations.

R2747 🔥

A CONSUMER MUST understand and process all WSDL 1.1 SOAP Binding extension elements, irrespective of the presence or absence of the wsdl:required attribute on an extension element; and irrespective of the value of the wsdl:required attribute, when present.

SOAP::WSDL does not implement all WSDL 1.1 SOAP Binding extension yet.

TODO: check and implement.

R2800 🌸

A DESCRIPTION MAY use any construct from XML Schema 1.0.

SOAP::WSDL's WSDL parser doen not allow all constructs from XML Schema 1.0 to be used.

TODO: become "minimal conformant".

💀 RULES NOT APPLICABLE 💀

Okay so these rules are not applicable to SOAP::WSDL, usually because it doesn't do the thing the rule is about. Still gotta list 'em all, bestie. Periodt. 💅

R0004 🎀

A MESSAGE MAY contain conformance claims, as specified in the conformance claim schema.

SOAP::WSDL::Serializer::SOAP11 does not add conformance claims. Other serializers may act different.

R0005 🌸

A MESSAGE's conformance claims MUST be carried as SOAP header blocks.

SOAP::WSDL::Serializer::SOAP11 does not add conformance claims. Other serializers may act different.

R0006 🦋

A MESSAGE MAY contain conformance claims for more than one profile.

SOAP::WSDL::Serializer::SOAP11 does not add conformance claims. Other serializers may act different.

R0007 💜

A SENDER MUST NOT use the soap:mustUnderstand attribute when sending a SOAP header block containing a conformance claim.

SOAP::WSDL::Serializer::SOAP11 does not add conformance claims. Other serializers may act different.

R3020 ⭐

REGDATA of type uddi:tModel claiming conformance with a Profile MUST be categorized using the ws-i-org:conformsTo:2002_12 taxonomy.

SOAP::WSDL does not publish web services yet.

R3030 🌈

REGDATA of type uddi:tModel claiming conformance with a Profile MUST use the ws-i-org:conformsTo:2002_12 categorization value corresponding to the conformance claim URI for that Profile.

SOAP::WSDL does not publish web services yet.

R3021 🎀

A REGISTRY MUST support the WS-I Conformance category system by adding the ws-i-org:conformsTo:2002_12 tModel definition to its registry content.

SOAP::WSDL does not publish web services yet.

R3005 🦋

REGDATA other than uddi:tModel elements representing conformant Web service types MUST NOT be categorized using the ws-i-org:conformsTo:2002_12 taxonomy and a categorization of "http://ws-i.org/profiles/basic/1.0".

SOAP::WSDL does not publish web services yet.

R3004 💅

REGDATA of type uddi:tModel MUST be constructed so that the conformance claim it makes is consistent with the conformance claim made by the wsdl:binding to which it refers.

SOAP::WSDL does not publish web services yet.

R1000 🔥

When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor and detail.

SOAP::WSDL does not send fault messages. However, SOAP::WSDL::SOAP::Typelib::Fault11 complies to this rule.

R1001 ✨

When a MESSAGE contains a soap:Fault element its element children MUST be unqualified.

SOAP::WSDL does not send fault messages. However, SOAP::WSDL::SOAP::Typelib::Fault11 complies to this rule.

R1004 🌸

When a MESSAGE contains a faultcode element the content of that element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace qualified fault code.

SOAP::WSDL does not send fault messages. However, the fault issued by SOAP::WSDL::Deserializer comply to this rule.

R1031 🦋

When a MESSAGE contains a faultcode element the content of that element SHOULD NOT use of the SOAP 1.1 "dot" notation to refine the meaning of the Fault.

SOAP::WSDL does not send fault messages. However, the fault issued by SOAP::WSDL::Deserializer comply to this rule.

R1013 💜

A MESSAGE containing a soap:mustUnderstand attribute MUST only use the lexical forms "0" and "1".

SOAP::WSDL does not add soap:mustUnderstand attributes.

R1025 ⭐

A RECEIVER MUST handle messages in such a way that it appears that all checking of mandatory header blocks is performed before any actual processing.

SOAP::WSDL does not check mandatory header blocks yet.

R1027 🌈

A RECEIVER MUST generate a "soap:MustUnderstand" fault when a message contains a mandatory header block (i.e., one that has a soap:mustUnderstand attribute with the value "1") targeted at the receiver (via soap:actor) that the receiver does not understand.

SOAP::WSDL does not check mandatory header blocks yet.

R1120 🎀

An INSTANCE MAY use the HTTP state mechanism ("Cookies").

SOAP::WSDL::Server::CGI does not use cookies. A web server running a SOAP::WSDL::Server::CGI script may use cookies..

R1122 🦋

An INSTANCE using Cookies SHOULD conform to RFC2965.

SOAP::WSDL::Server::CGI does not use cookies. A web server running a SOAP::WSDL::Server::CGI script may use cookies..

R1121 💅

An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly

SOAP::WSDL::Server::CGI does not use cookies. A web server running a SOAP::WSDL::Server::CGI script may use cookies.

R1123 🔥

The value of the cookie MUST be considered to be opaque by the CONSUMER.

SOAP::WSDL::Server::CGI does not use cookies. A web server running a SOAP::WSDL::Server::CGI script may use cookies.

R2028 ✨

A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".

See 2029.

R2029 🌸

A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at "http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

Although the Profile requires WSDL descriptions to be Schema valid, it does not require consumers to validate WSDL documents.

It is the responsibility of a WSDL document's author to assure that it is Schema valid.

R2001 🦋

A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description.

SOAP::WSDL (partially) supports the wsdl:import statement. The wsdl:include statement is not supported.

It's the responsibility of the WSDL author to use only the wsdl:import statement for importing WSDL descriptions.

R2002 💜

To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement.

SOAP::WSDL has no means of generating WSDL definitions.

R2003 ⭐

A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section.

SOAP::WSDL has no means of generating WSDL definitions.

R2004 🌈

A DESCRIPTION MUST NOT use the XML Schema "import" statement to import a Schema from any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema".

SOAP::WSDL has no means of generating WSDL definitions.

R2009 🎀

An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).

SOAP::WSDL has no means of generating WSDL definitions.

R2010 🦋

An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.

SOAP::WSDL has no means of generating WSDL definitions.

R2011 💅

An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.

SOAP::WSDL has no means of generating WSDL definitions.

R2007 🔥

A DESCRIPTION MUST specify a non-empty location attribute on the wsdl:import element.

SOAP::WSDL has no means of generating WSDL definitions.

R2022 ✨

When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements from the WSDL namespace except wsdl:documentation.

SOAP::WSDL has no means of generating WSDL definitions.

R2023

When they appear in a DESCRIPTION, wsdl:types elements MUST precede all other elements from the WSDL namespace except wsdl:documentation and wsdl:import.

SOAP::WSDL has no means of generating WSDL definitions, bestie, so this one isn't ours to trip over. 💅

R4004

A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.

SOAP::WSDL has no means of generating WSDL definitions. ✨

R2005

The targetNamespace attribute on the wsdl:definitions element of a description that is being imported MUST have same the value as the namespace attribute on the wsdl:import element in the importing DESCRIPTION.

SOAP::WSDL has no means of generating WSDL definitions — so, respectfully, not our problem. 🎀

R2021

The wsdl:documentation element MAY occur as a child of the wsdl:part element in a DESCRIPTION.

SOAP::WSDL has no means of generating WSDL definitions. 🦋

R2025

A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile.

SOAP::WSDL has no means of generating WSDL definitions. No generating, no contradicting, no drama. 🌸

R2026

A DESCRIPTION SHOULD NOT include extension elements with a wsdl:required attribute value of "true" on any WSDL construct (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types or wsdl:import) that claims conformance to the Profile.

SOAP::WSDL has no means of generating WSDL definitions. 🫶

R2101

A DESCRIPTION MUST NOT use QName references to elements in namespaces that have been neither imported, nor defined in the referring WSDL document.

SOAP::WSDL has no means of generating WSDL definitions. 😭

R2102

A QName reference to a Schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element.

SOAP::WSDL has no means of generating WSDL definitions. 💜

R2105

All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).

SOAP::WSDL has no means of generating WSDL definitions. 🌈

R2110

In a DESCRIPTION, array declarations MUST NOT extend or restrict the soapenc:Array type.

SOAP::WSDL has no means of generating WSDL definitions. 🍓

R2111

In a DESCRIPTION, array declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

SOAP::WSDL has no means of generating WSDL definitions. 🧚

R2112

In a DESCRIPTION, array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX.

SOAP::WSDL has no means of generating WSDL definitions. 💖

R2201

A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

SOAP::WSDL has no means of generating WSDL definitions. ✨

R2210

If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl:parts.

SOAP::WSDL has no means of generating WSDL definitions. 💅

R2202

A wsdl:binding in a DESCRIPTION MAY contain soapbind:body element(s) that specify that zero parts form the soap:Body.

SOAP::WSDL has no means of generating WSDL definitions. 🔥

R2203

An rpc-literal binding in a DESCRIPTION MUST refer, in its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the type attribute.

SOAP::WSDL has no means of generating WSDL definitions. 👑

R2211

A MESSAGE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of "1" or "true" on the part accessors.

(No SOAP::WSDL note on this one, bestie — it just sits there, vibing.) 💀

R2207

A wsdl:message in a DESCRIPTION MAY contain wsdl:parts that use the elements attribute provided those wsdl:parts are not referred to by a soapbind:body in an rpc-literal binding.

SOAP::WSDL has no means of generating WSDL definitions. 🎀

R2204

A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.

SOAP::WSDL has no means of generating WSDL definitions.

Note: SOAP::WSDL requires that a DESCRIPTION confirms to these rules.

R2208

A binding in a DESCRIPTION MAY contain soapbind:header element(s) that refer to wsdl:parts in the same wsdl:message that are referred to by its soapbind:body element(s).

(No extra note here either — it just is what it is.) 🌸

R2205

A wsdl:binding in a DESCRIPTION MUST refer, in each of its soapbind:header, soapbind:headerfault and soapbind:fault elements, only to wsdl:part element(s) that have been defined using the element attribute.

SOAP::WSDL has no means of generating WSDL definitions. 🦋

R2209

A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault.

SOAP::WSDL has no means of generating WSDL definitions. 💜

R2206

A wsdl:message in a DESCRIPTION containing a wsdl:part that uses the element attribute MUST refer, in that attribute, to a global element declaration.

SOAP::WSDL has no means of generating WSDL definitions. 🫶

R2302

A DESCRIPTION MAY use the parameterOrder attribute of an wsdl:operation element to indicate the return value and method signatures as a hint to code generators.

SOAP::WSDL has no means of generating WSDL definitions. ✨

R2303

A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

(No SOAP::WSDL note attached — noted and moved on.) 🌈

R2304

A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes.
Note: SOAP::WSDL requires that a DESCRIPTION confirms to these rules.

R2305

A wsdl:portType in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message.

(That's the whole rule, no footnote, no commentary. Slay.) 💅

R2306

A wsdl:message in a DESCRIPTION MUST NOT specify both type and element attributes on the same wsdl:part.

SOAP::WSDL has no means of generating WSDL definitions. 🍓

R2401

A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

SOAP::WSDL has no means of generating WSDL definitions. 🧚

R2701

The wsdl:binding element in a DESCRIPTION MUST be constructed so that its soapbind:binding child element specifies the transport attribute.

SOAP::WSDL has no means of generating WSDL definitions. 💖

R2702

A wsdl:binding element in a DESCRIPTION MUST specify the HTTP transport protocol with SOAP binding. Specifically, the transport attribute of its soapbind:binding child MUST have the value "http://schemas.xmlsoap.org/soap/http".

SOAP::WSDL has no means of generating WSDL definitions. 🔥

R2705

A wsdl:binding in a DESCRIPTION MUST use either be a rpc-literal binding or a document-literal binding.

SOAP::WSDL has no means of generating WSDL definitions.

Note: SOAP::WSDL does not support rpc-literal bindings yet.

R2706

A wsdl:binding in a DESCRIPTION MUST use the value of "literal" for the use attribute in all soapbind:body, soapbind:fault, soapbind:header and soapbind:headerfault elements.

SOAP::WSDL has no means of generating WSDL definitions. 👑

R2707

A wsdl:binding in a DESCRIPTION that contains one or more soapbind:body, soapbind:fault, soapbind:header or soapbind:headerfault elements that do not specify the use attribute MUST be interpreted as though the value "literal" had been specified in each case.

SOAP::WSDL has no means of generating WSDL definitions. 💅

R2709

A wsdl:portType in a DESCRIPTION MAY have zero or more wsdl:bindings that refer to it, defined in the same or other WSDL documents.

SOAP::WSDL has no means of generating WSDL definitions. 🎀

R2710

The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another.

SOAP::WSDL has no means of generating WSDL definitions. 🌸

R2711

A DESCRIPTION SHOULD NOT have more than one wsdl:port with the same value for the location attribute of the soapbind:address element.

SOAP::WSDL has no means of generating WSDL definitions. 🦋

R2714

For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains a SOAP envelope. Specifically, the HTTP response entity-body must be empty.

SOAP::WSDL does not act as a server, yet. 😭

R2727

For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it.

SOAP::WSDL regards a successful HTTP status code for a one-way operation as an acknowledgement of the RECEIVER having receive (not processed!) the message.

SOAP::WSDL makes no assumptions about the processing of SOAP messages, but higher level clients may do. 💜

R2716

A document-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained soapbind:body, soapbind:header, soapbind:headerfault and soapbind:fault elements.

SOAP::WSDL has no means of generating WSDL definitions. 🌈

R2717

An rpc-literal binding in a DESCRIPTION MUST have the namespace attribute specified, the value of which MUST be an absolute URI, on contained soapbind:body elements.

SOAP::WSDL has no means of generating WSDL definitions. 🍓

R2726

An rpc-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained soapbind:header, soapbind:headerfault and soapbind:fault elements.

SOAP::WSDL has no means of generating WSDL definitions. 🧚

R2718

A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operations as the wsdl:portType to which it refers

SOAP::WSDL has no means of generating WSDL definitions. 💖

R2719

A wsdl:binding in a DESCRIPTION MAY contain no soapbind:headerfault elements if there are no known header faults.

SOAP::WSDL has no means of generating WSDL definitions. ✨

R2740

A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:fault describing each known fault.

SOAP::WSDL has no means of generating WSDL definitions. 🔥

R2741

A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:headerfault describing each known header fault.

SOAP::WSDL has no means of generating WSDL definitions. 👑

R2743

A MESSAGE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a wsdl:headerfault element in the corresponding WSDL description.

(No footnote here either, bestie — it just stands on its own.) 💅

R2720

A wsdl:binding in a DESCRIPTION MUST use the attribute named part with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements.
  • R2749 — bestie, a wsdl:binding in a DESCRIPTION MUST NOT use the attribute named parts on any contained soapbind:header and soapbind:headerfault elements. Not even a little. 🙅‍♀️
  • R2721 — every contained soapbind:fault element inside a wsdl:binding in a DESCRIPTION MUST have the name attribute specified. All of them, no skipping. 💅
  • R2754 — in a DESCRIPTION, the value of the name attribute on a soapbind:fault element MUST match the value of the name attribute on its parent wsdl:fault element. They gotta twinning, fr fr. 👯
  • R2722 — a wsdl:binding in a DESCRIPTION MAY specify the use attribute on contained soapbind:fault elements. Optional, bestie. ✨
  • R2723 — if that use attribute on a contained soapbind:fault element is present in a wsdl:binding in a DESCRIPTION, its value MUST be "literal". Literally literal. 💀
  • R2728 — a wsdl:binding in a DESCRIPTION that omits the use attribute on a contained soapbind:fault element MUST be interpreted as though use="literal" had been specified. So silence = literal. 🤫
  • R2724 — if an INSTANCE gets a message that’s inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of "Client" — unless a "MustUnderstand" or "VersionMismatch" fault is generated. Priorities, bestie. 😤
  • R2725 — same situation, an INSTANCE MUST check for "VersionMismatch", "MustUnderstand" and "Client" fault conditions in that order. Order matters, periodt. 🚨
  • R2729 — a MESSAGE described with an rpc-literal binding that is a response message MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string "Response". Name it and claim it. 🎀
  • R2735 — a MESSAGE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace. Nowhere, nope. 🕳️
  • R2737 — a MESSAGE described with an rpc-literal binding MUST namespace qualify the children of part accessor elements for the parameters and the return value with the targetNamespace in which their types are defined. Put some respect on that namespace. 🌈
  • R2738 — a MESSAGE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it. All of them. No ghosting headers. 👻
  • R2739 — a MESSAGE MAY contain SOAP header blocks that are not described in the wsdl:binding that describes it. Surprise headers? Allowed. 🎁
  • R2753 — if a MESSAGE contains SOAP header blocks not described in the appropriate wsdl:binding, it MAY have the mustUnderstand attribute on such SOAP header blocks set to '1'. You can flag ’em. 🚩
  • R2751 — the order of soapbind:header elements in soapbind:binding sections of a DESCRIPTION MUST be considered independent of the order of SOAP header blocks in the message. Order? Not related, bestie. 🔀
  • R2752 — a MESSAGE MAY contain more than one instance of each SOAP header block for each soapbind:header element in the appropriate child of soapbind:binding in the corresponding description. Duplicates? It’s giving allowed. 👯‍♀️
  • R2801 — a DESCRIPTION MUST use XML Schema 1.0 Recommendation as the basis of user defined datatypes and structures. Old but gold, no cap. 📜
  • R3100 — REGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element. Gotta have it. 🔑
  • R3002 — REGDATA of type uddi:tModel representing a conformant Web service type MUST use WSDL as the description language. WSDL only. 💅
  • R3003 — REGDATA of type uddi:tModel representing a conformant Web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec". Categorize, bestie. 🏷️
  • R3010 — REGDATA of type uddi:tModel representing a conformant Web service type MUST follow V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry. Follow the bestie practice. 📘
  • R3011 — the wsdl:binding referenced by REGDATA of type uddi:tModel MUST itself conform to the Profile. No exceptions. ✅
  • R5001 — if an INSTANCE requires HTTPS, the location attribute of the soapbind:address element in its wsdl:port description MUST be a URI whose scheme is "https"; otherwise it MUST be a URI whose scheme is "http". Secure or not secure, pick one. 🔒/🔓
Heads up: SOAP::WSDL has no means of generating WSDL definitions. It’s just not that girl for that job. 💅

Okay so legal moment, bestie. This file contains quotes from <http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html>. To these quotes, the legal notice from the document source applies. 📜

The rest of this file: Copyright 2007 Martin Kutter. ✨

This file is part of SOAP-WSDL. You may distribute/modify it under the same terms as perl itself. 🫶

🌸 AUTHOR 🌸

Martin Kutter <martin.kutter fen-net.de> — that’s the author, bestie. 💌

🦋 REPOSITORY INFORMATION 🦋

These are the repo vibes, bestie:

$Rev: 562 $
$LastChangedBy: kutterma $
$Id: WS_I.pod 562 2008-02-22 20:32:17Z kutterma $
$HeadURL: https://soap-wsdl.svn.sourceforge.net/svnroot/soap-wsdl/SOAP-WSDL/trunk/lib/SOAP/WSDL/Manual/WS_I.pod $

💖 And that’s the whole page, bestie! This one comes from perl v5.36.0, dated 2022-10-14, and it lives in SOAP::...::WS_I(3pm). Slay! ✨

📦 where this page comes from