[R4xx] Application of XML Protocol Requirements to SOAP/1.1

Requirement: The XML Protocol data encapsulation and data representation
mechanisms must be orthogonal.

Comment: SOAP/1.1 provides a data model and a proposed serialization of that
model using the encoding provided in section 5 [1]. Both the data model and
the data serialization is orthogonal to the data encapsulation (the SOAP
envelope [2]). In [1] it is stated that the two are orthogonal:

    Use of the data model and encoding style described in
    this section is encouraged but not required; other data
    models and encodings can be used in conjunction with
    SOAP (see section 4.1.1).

The SOAP envelope provides a mechanism in form of the "encodingStyle"
attribute [3] that allows other data models and data serialization
to be used,

Judgement: SOAP/1.1 covers this requirement

Requirement: The XML Protocol data representation must support using XML
Schema simple and complex types.

Comment: SOAP/1.1 adopts all simple types defined by XML Schema as described
in [4]:

    For simple types, SOAP adopts all the types found in the
    section "Built-in datatypes" of the "XML Schema Part 2:
    Datatypes" Specification, both the value and lexical spaces.

The SOAP/1.1 data model supports the use of XML schema complex types
although it does not support the use of attributes for carrying instance
values. The reason is that the SOAP/1.1 serialization mechanism reserves
attributes for book keeping of the serialization and does not allows the
application to otherwise use attributes. Therefore, XML instances using
attributes for carrying instance data do not follow the SOAP serialization.

There are two ways around this: generate a schema as described in the
comment of R402 or not to use the SOAP serialization model. As one of the
goals of the SOAP serialization is to limit the ways instance data can be
encoded, the limitation of attributes is not considered as a disadvantage.

Judgement: SOAP/1.1 supports simple types and support complex types with the
exception of attributes which are reserved for the SOAP serialization. The
perceived benefit of this limitation is that it provides a simpler mapping
to common programming language constructs. It is therefore judged that this
requirement is met given the stated limitation.

Requirement: The XML Protocol data representation must be able to serialize
data based on
data models not directly representable by XML Schema simple and complex
These data models include object graphs and directed labeled graphs. It must
be possible to reconstruct the original data from the data representation.

Comment: SOAP/1.1 states [6] that given any data model that can be expressed
using the SOAP/1.1 data model consisting of simple types, complex types, and
references, it is possible to create an XML schema representing that model.
Next, given a particular instance of values (for example a graph) expressed
using that XML schema, it is possible to create an XML instance representing
those values. This XML instance is what is being transferred within a SOAP
message. The recipient of a SOAP message can given the XML schema and the
XML instance recreate the original value (for example a graph).

Judgement: The current SOAP/1.1 model seems to be capable of representing
directed graphs as well as object graphs and enable a recipient to
deserialize an XML instance to recreate those graphs. It is not clear
whether there are other data models that potentially are interesting to
serialize but not representable within the SOAP data model.

Requirement: Data serialized according to the XML Protocol data
representation may contain references to data outside the serialization.
These references must be Uniform
Resource Identifiers (URIs).

Comment: The SOAP/1.1 encoding uses the "id" and "href" attributes to name
and refer to resources or sub-parts of resources. The format of the href
attribute is of type "uri-reference" as defined by XML schema. The "id"
attribute is of type "ID" as defined by XML/1.0. There are no restrictions
on the value of a URI used as value in a href attribute.

Judgement: SOAP/1.1 covers this requirement although it is not explicitly
stated that URIs can in fact point to anything.

Requirement: The XML Protocol data representation must be able to encode
arrays which may
be nested.

Comment: The SOAP/1.1 data model defines an array type [5]:

    SOAP arrays are defined as having a type of
    "SOAP-ENC:Array" or a type derived there from (see also
    rule 8). Arrays are represented as element values, with
    no specific constraint on the name of the containing
    element (just as values generally do not constrain the
    name of their containing element). 

as well as the encoding mechanism defines a serialization of that array

    The representation of the value of an array is an
    ordered sequence of elements constituting the items of
    the array. Within an array value, element names are not
    significant for distinguishing accessors. Elements may
    have any name.

and can be nested:

    Arrays can contain elements which themselves can be of
    any type, including nested arrays. 

Mapping: SOAP/1.1 covers this requirement

[1] http://www.w3.org/TR/SOAP/#_Toc478383512
[2] http://www.w3.org/TR/SOAP/#_Toc478383494
[3] http://www.w3.org/TR/SOAP/#_Toc478383495
[4] http://www.w3.org/TR/SOAP/#_Toc478383514
[5] http://www.w3.org/TR/SOAP/#_Toc478383522

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 

Received on Wednesday, 7 February 2001 11:36:11 UTC