SOAP Version 1.2 Part 2: Adjuncts (Second Edition) (2025)

B.1 Rules for Mapping Application-Defined Names to XML Names

1. An XML Name has two parts: Prefix and LocalPart. Let Prefix be determined per the rules and constraints specified in Namespaces in XML [Namespaces in XML].

2. Let T be a name in an application, represented asa sequence of characters encoded in a particular character encoding.

3. Let M be the implementation-defined function fortranscoding of the characters used in the application-definedname to an equivalent string of Unicode characters.

   Note:

   Ideally, if this transcoding is from anon-Unicode encoding, it should be both reversible and UnicodeForm C normalizing (that is, combining sequences will be inthe prescribed canonical order). It should be noted that sometranscodings cannot be perfectly reversible and that Normalization Form C (NFC)normalization may alter the original sequence in a fewcases (see Character Model for the World Wide Web [CharMod]). Toensure that matching names continue to match after mapping,Unicode sequences should be normalized using UnicodeNormalization Form C.

   Note:

   This transcoding is explicitly to Unicodescalar values ("code points") and not to any particularcharacter encoding scheme of Unicode, such as UTF-8 or UTF-16.

   See Also

   Tutorial zu SOAP-Webdiensten: Was ist das SOAP-Protokoll? BEISPIELSOAP Web Services Tutorial: What is SOAP Protocol? EXAMPLE

   Note:

   Note: Properly formed surrogate pairsequences must be converted to their respective scalar values("code points") [That is, the sequence U+D800 U+DC00 should betranscoded to the character U+10000]. If the transcodingbegins with a Unicode encoding, non-conforming (non-shortestform) UTF-8 and UTF-16 sequences must be converted to theirrespective scalar values.

   Note:

   The number of characters in T is notnecessarily the same as the number of characters in M, becausetranscoding may be one-to-many or many-to-one. The details oftranscoding may be implementation-defined. There may be (veryrarely) cases where there is no equivalent Unicoderepresentation for T; such cases are not covered here.

4. Let C be the sequence of Unicodescalar values (characters) represented by M(T)

5. Let N be the number of characters inC. Let C₁,C₂, ..., C_N be thecharacters of C, in order from most to leastsignificant (logical order).

6. For each i between 1 (one) andN, let X_i be the Unicodecharacter string defined by the following rules:

   Case:

   1. If C_i is undefined (that is, some character or sequence of characters as defined in the application's character sequence T contains no mapping to Unicode), then X_i is implementation-defined.

   2. If i<=N-1 and C_i is "_" (U+005F LOW LINE) and C_i+1 is "x" (U+0078 LATIN SMALL LETTER X), then let X_i be "_x005F_".

   3. If i=1, and N>=3, and C₁ is "x" (U+0078 LATIN SMALL LETTER X) or "X" (U+0058 LATIN CAPITAL LETTER X), and C₂ is "m" (U+006D LATIN SMALL LETTER M) or "M" (U+004D LATIN CAPITAL LETTER M), and C₃ is "l" (U+006C LATIN SMALL LETTER L) or "L" (U+004C LATIN CAPITAL LETTER L) (in other words, a string three letters or longer starting with the text "xml" or any re-capitalization thereof), then if C₁ is "x" (U+0078 LATIN SMALL LETTER X) then let X₁ be "_x0078_"; otherwise, if C₁ is "X" (U+0058 LATIN CAPITAL LETTER X) then let X₁ be "_x0058_".

   4. If C_i is not a valid XML NCName character (see Namespaces in XML [Namespaces in XML]) or if i=1 (one) and C₁ is not a valid first character of an XML NCName then:

      Let U₁, U₂, ... , U₆ be the six hex digits [PROD: 5] such that C_i is "U+" U₁ U₂ ... U₆ in the Unicode scalar value.

      Case:

      1. If U₁=0, U₂=0, U₃=0, and U₄=0, then let X_i="_x" U₅ U₆ "_".

         This case implies that C_i is a character in the Basic Multilingual Plane (Plane 0) of Unicode and can be wholly represented by a single UTF-16 code point sequence U+U₅U₆.

      2. Otherwise, let X_i be "_x" U₁ U₂ U₃ U₄ U₅ U₆ "_".

   5. Otherwise, let X_i be M_i. That is, any character in X that is a valid character in an XML NCName is simply copied.

7. Let LocalPart be the character string concatenation of X₁, X₂, ... , X_N in order from most to least significant.

8. Let XML Name be the QName per Namespaces in XML [Namespaces in XML]

B.2 Examples

Hello world -> Hello_x0020_worldHello_xorld -> Hello_x005F_xorldHelloworld_ -> Helloworld_ x -> x xml -> _x0078_ml -xml -> _x002D_xml x-ml -> x-ml Ælfred -> Ælfred άγνωστος -> άγνωστοςᜉᜅᜎᜈ -> _x1709__x1705__x170E__x1708_ᏙᏚᎥ -> _x13D9__x13DA__x13A5_ 

C.1 Validating Using the Minimum Schema

Although W3C XML schemas are conventionally exchanged in theform of schema documents (see XML Schema [XML Schema Part 1]), the schemaRecommendation is built on an abstract definition of schemas,to which all processors need to conform. The schemaRecommendation provides that all such schemas includedefinitions for a core set of built in types, such asintegers, dates, and so on (see XML Schema [XML Schema Part 1], Built-in Simple Type Definition). Thus, it is possible to discuss validation of a SOAPmessage against such a minimal schema, which is the one thatwould result from providing no additional definitions ordeclarations (i.e., no schema document) to a schema processor.

The minimal schema provides that any well formed XML documentwill validate, except that where an xsi:type is provided, thetype named must be built in, and the corresponding element must bevalid per that type. Thus, validation of a SOAP 1.2 message using aminimal schema approximates the behavior of the built-in typesof SOAP 1.1.

C.2 Validating Using the SOAP Encoding Schema

Validation against the minimal schema (see C.1 Validating Using the Minimum Schema) will not succeed where encoded graph nodeshave multiple inbound edges. This is becauseelements representing such graph nodes will carry id attribute information items which are not legalon elements of type "xs:string","xs:integer" etc. The SOAP Encoding of such graphs MAY be validatedagainst the SOAP Encoding schema.In order for the encoding to validate, edge labels, andhence the[local name] and [namespace name] properties of theelement information items, need to match thosedefined in the SOAP Encoding schema. Validation of the encodedgraph against the SOAP Encoding schema would result in thetype name property of the nodes in the graph being assignedthe relevant type name.

C.3 Validating Using More Specific Schemas

It may be that schemas could be constructed to describe the encoding ofcertain graphs. Validation of the encoded graph against such a schema wouldresult in the type name property of the graph nodes being assigned therelevant type name. Such a schema can also supply default or fixed valuesfor one or more of the itemType , arraySize or nodeType attributeinformation items; the values of such defaulted attributes affect thedeserialized graph in the same manner as if the attributes had beenexplicitly supplied in the message. Errors or inconsistencies thusintroduced (e.g. if the value of the attribute is erroneous or inappropriate)should be reported as application-level errors; faults from the "http://www.w3.org/2003/05/soap-encoding"namespace should be reported only if the normative parts of thisspecification are violated.