XMLP/SOAP Terms Table

Does not directly define the term "SOAP" but mentions that "SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML."

XMLP is not in conflict but a useful clarification of SOAP and what it means to be a protocol.

[ref] All immediate child elements of the Header element are called header entries. A header entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the SOAP Header element MUST be namespace-qualified.

[ref] All immediate child elements of the Body element are called body entries and each body entry is encoded as an independent element within the SOAP Body element. A body entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. Immediate child elements of the SOAP Body element MAY be namespace-qualified.

The basic notion of blocks and "entries" are similar in their purpose and location (see also figure 2) although the SOAP definition is somewhat more specific. In both cases do they (implicitly) provide a  "syntactic delimiter for a computational unit" within the composability model. SOAP, however, is much more specific in how an entry is identified and how it is located: by the fully qualified name of the outer entry element of the entry consisting of the namespace URI and the local name. This model is also consistent with the type-model provided by XSD etc.

The problem remains, however, that the current definition says nothing about what a block constitutes, how it is identified, or that it is not just any old bit of XML but a piece of XML that is special to the XML processor. In contrast, the previous definition provided by the first published revision of the requirements document is much clearer in what a block actually delimits: "A syntactic construct or structure used to delimit data that logically constitutes a single computational unit as seen by an XP processor".

n/a

SOAP does not talk about how or what is responsible for processing the block: at the handler level but keeps it at the XMLP Node level meaning that the overall SOAP sender or SOAP receiver is responsible for generating and parsing a SOAP message respectively. By not differentiating between handlers and the processor, SOAP avoids getting into the business of defining any internals of how a SOAP processor is implemented and whether it provides a plug-in mechanism for software modules or not.

When reading the XMLP handler definition, it is not clear whether it describes an actual software module or whether it is an abstract notion of some computational unit. In the former case this would mean that we actually are proposing an implementation model which I don't think we are. It is also not clear what "targeted at it" means.

The current XMLP handler definition is sufficiently unclear to not be able to describe the SOAP model. The previous definition provided by the first published revision of the requirements document seems to be clearer: "An abstraction for the processing and/or logic required to implement a feature or function typically through the transmission or exchange of XP blocks".

However, one problem remains which is that there are many "handlers" that exist in the world which are not part of modules. Say I have an application that can deal with a copyright statement - this app has never known anything about SOAP or XMLP - it just gets fed a copyright statement that might have been included in a SOAP message as a block or might have been read from tape etc.

I don't think this is what we mean when we talk about a module - I suspect that we mean a "SOAP/XMLP based protocol that provides some service or function that is related to SOAP/XMLP in some manner. Examples of services include signing, encryption, caching, routing, reliability, privacy, logging, tracing, etc.

An example of a module is the SOAP Dsig W3C Note, which defines a processing model for what it means to "mustUnderstand" the module. However, the Dsig specification itself is not a module. Similarly, in the case of the copyright statement, if I have a module that defines the protocol behavior for what it means to "mustUnderstand" then I have a module - otherwise I just have a copyright statement. The copyright statement block might be referred to by other blocks in that it might be signed etc., but simply by itself, it is not part of a module.

Talks loosely about how the compositional model can be used to introduce services

The XMLP definition of a module is in fact in line with the proposed solutions for handler and block but uses the term "realizes" where "provided" might be a more appropriate term.

Doesn't provide a definition in the abstract but rather in terms of the two bindings provided by the SOAP spec:

[ref] In addition to the SOAP envelope, the SOAP encoding rules and the SOAP RPC conventions, this specification defines two protocol bindings that describe how a SOAP message can be carried in HTTP [5] messages either with or without the HTTP Extension Framework [6].

There is no apparent conflict between the two

SOAP implicitly talks about this but doesn't make it clear

There is no apparent conflict between the two

SOAP defines a SOAP processor in terms of what it has to do [ref]:

A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below:

1. Identify all parts of the SOAP message intended for that application (see section 4.2.2)
2. Verify that all mandatory parts identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. If this is not the case then discard the message (see section 4.4). The processor MAY ignore optional parts identified in step 1 without affecting the outcome of the processing.
3. If the SOAP application is not the ultimate destination of the message then remove all parts identified in step 1 before forwarding the message.

It is not clear what "enforcing the rules that govern the exchange of XMLP messages" means. Also, as SOAP doesn't talk about the notion of handlers at all, the part "An XMLP processor is responsible for invoking local XMLP Handlers and providing the services of the XMLP layer to those XMLP handlers", it is not clear how this applies to SOAP. This model of handlers as described earlier is very "software component" oriented which SOAP doesn't get into.

In SOAP this is defined by the envelope schema

The XMLP definition is a verbal abstraction of the SOAP schema definition

In SOAP this is defined by the envelope schema

The XMLP definition is a verbal abstraction of the SOAP schema definition

In SOAP this is defined by the envelope schema

The XMLP definition is a verbal abstraction of the SOAP schema definition

In SOAP this is defined by the envelope schema along with a description:

[ref] The SOAP Fault element is used to carry error and/or status information within a SOAP message. If present, the SOAP Fault element MUST appear as a body entry and MUST NOT appear more than once within a Body element.

The SOAP definition is more specific on where the fault can occur within the message and how many faults there can be (one) but otherwise they are quite similar

SOAP loosely calls this a SOAP application [ref]

There is no particular conflict in these definitions

SOAP loosely talks about a sender [ref]

There is no particular conflict in these definitions

SOAP loosely talks about a sender [ref]

There is no particular conflict in these definitions

SOAP loosely talks about a sender [ref]

There is no particular conflict in these definitions

SOAP doesn't call this out explicitly

This doesn't conflict with the SOAP model

SOAP talks about intermediaries [ref]

Regardless of the protocol to which SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination.

no conflict

SOAP doesn't call this out explicitly

This doesn't conflict with the SOAP model

SOAP is a bit fuzzy on what it considers the data model and what it considers the serialization of that data model. This has been noted as an issue

Given the issue, this doesn't conflict with the SOAP model

As above, this is slightly fuzzy in SOAP but the definition of the encoding is described in section 5.

Given the issue, this doesn't conflict with the SOAP model