W3CArchitecture Domain XML Protocol WG

XMLP/SOAP Terms Table

Last Updated: $Date: 2001/03/22 19:27:33 $ UTC

Note that the issues list contains several comments on the various definitions of SOAP terms.

Comments on this table should be sent to the xml-dist-app@w3.org mailing list (Archives)

id Term Description
1 XMLP

The formal set of conventions governing the format and processing rules of an XMLP message and basic control of interaction among applications generating and accepting XMLP messages for the purpose of exchanging information along an XMLP message path.

SOAP

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."

Comparison

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

Proposed Resolution

Use the XMLP definition for SOAP

3 XMLP block

The syntactic construct or structure defined in an XMLP module. XMLP blocks are processed by XMLP handlers.

SOAP Header entry and Body entry

[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.

Comparison

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".

Proposed Resolution

Use the term "block" but revert to the previous definition and add the SOAP mechanism for identifying the block based on the fully qualified name of the outer element:

"A syntactic construct or structure used to delimit data that logically constitutes a single computational unit as seen by an XMLP processor. A block is identified by the fully qualified name of the outer element for the block, which consists of the namespace URI and the local name."

This definition makes it clear that if blocks are nested then it is only the outer block that is looked from the XMLP processor's point of view. The inner contents of a block is only looked at if the block is processed. It also doesn't tie a block to necessarily be part of any module.

4 XMLP handler

An XMLP handler is responsible for processing XMLP Blocks targeted at it according to any rules defined in the corresponding XMLP module.

SOAP

n/a

Comparison

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.

Proposed Resolution

Keep the term "handler" but revise the definition to say:

"An abstraction for the processing and/or logic defined by an XMLP module typically involving transmission or exchange of XMLP blocks.".

5 XMLP module

An XMLP module is a basic unit for the definition of extensions to XMLP. An XMLP module encapsulates the definition of one or more related XMLP blocks and their associated processing rules. These processing rules are realised in one or more XMLP handlers.

SOAP

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

Comparison

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.

Proposed Resolution

Use the XMLP module term but update it to say:

"An XMLP module is a basic unit for the definition of extensions to XMLP. An XMLP module encapsulates the definition of one or more XMLP blocks and one or more XMLP handlers."

6 XMLP binding

The formal set of rules for carrying an XMLP message within or on top of another protocol for the purpose of transmission. Typical XMLP bindings include carrying an XMLP message within an HTTP message, or on top of TCP.

SOAP

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].

Comparison

There is no apparent conflict between the two

Proposed Resolution

Introduce the binding definition into the SOAP spec

7 XMLP message

An XMLP message is the basic unit of communication between peer XMLP processors.

SOAP

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

Comparison

There is no apparent conflict between the two

Proposed Resolution

Introduce the message definition into the SOAP spec

8 XMLP processor

An XMLP Processor processes an XMLP message according to the formal set of conventions defined by XMLP. It is responsible for enforcing the rules that govern the exchange of XMLP messages and accesses the services provided by the underlying protocols through XMLP bindings. An XMLP processor is responsible for invoking local XMLP Handlers and providing the services of the XMLP layer to those XMLP handlers.

Non-compliance with XMLP conventions or failure in an XMLP handler can cause an XMLP processor to generate an XMLP fault (see also XMLP receiver and XMLP sender).

SOAP

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.
Comparison

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.

Proposed Resolution

Keep the definition of processor but adjust it to talk about handlers as abstract notions that can take part of the processing:

An XMLP Processor processes an XMLP message according to the formal set of conventions defined by XMLP. Parts of a an XMLP message may be processed by handlers. The XML processor is responsible for enforcing the rules that govern the exchange of XMLP messages and accesses the services provided by the underlying protocols through XMLP bindings.

Non-compliance with XMLP conventions or failure in an XMLP handler can cause an XMLP processor to generate an XMLP fault (see also XMLP receiver and XMLP sender).

9 XMLP envelope

The outermost syntactical construct or structure of an XMLP message defined by XMLP within which all other syntactical elements of the message are enclosed.

SOAP

In SOAP this is defined by the envelope schema

Comparison

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

Proposed Resolution

Use the XMLP definition to clarify the SOAP schema definition

10 XMLP header

A collection or zero or more XMLP blocks which may be targeted at any XMLP receiver within the XMLP message path

SOAP

In SOAP this is defined by the envelope schema

Comparison

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

Proposed Resolution

Use the XMLP definition to clarify the SOAP schema definition

11 XMLP body

A collection or zero, or more XMLP blocks targeted at the ultimate XMLP receiver within the XMLP message path.

SOAP

In SOAP this is defined by the envelope schema

Comparison

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

Proposed Resolution

Use the XMLP definition to clarify the SOAP schema definition

12 XMLP fault

A special XMLP block which contains fault information generated by an XMLP processor or handler.

SOAP

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.

Comparison

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

Proposed Resolution

Introduce the XMLP definition to clarify the SOAP fault definition

13 XMLP node

An XMLP Node is an encapsulation of XMLP handlers and their associated XMLP processor.

SOAP

SOAP loosely calls this a SOAP application [ref]

Comparison

There is no particular conflict in these definitions

Proposed Resolution

Use the term "node" instead of "application"

14 XMLP sender

An XMLP Sender is an XMLP Node that transmits an XMLP Message.

SOAP

SOAP loosely talks about a sender [ref]

Comparison

There is no particular conflict in these definitions

Proposed Resolution

Introduce the XMLP definition to clarify the SOAP definition

15 XMLP receiver

An XMLP Receiver is an XMLP Node that accepts an XMLP Message.

SOAP

SOAP loosely talks about a sender [ref]

Comparison

There is no particular conflict in these definitions

Proposed Resolution

Introduce the XMLP definition to clarify the SOAP definition

16 XMLP message path

The set of XMLP senders and XMLP receivers through which a single XMLP message passes. This includes the initial XMLP sender, zero or more XMLP intermediaries, and the ultimate XMLP receiver.

SOAP

SOAP loosely talks about a sender [ref]

Comparison

There is no particular conflict in these definitions

Proposed Resolution

Introduce the XMLP definition to clarify the SOAP definition

17 initial XMLP sender

The XMLP sender that originates an XMLP message as the starting point of an XMLP message path.

SOAP

SOAP doesn't call this out explicitly

Comparison

This doesn't conflict with the SOAP model

Proposed Resolution

Introduce the XMLP definition

18 XMLP intermediary

An XMLP intermediary is both an XMLP receiver and an XMLP sender, target-able from within an XMLP message. It processes a defined set of blocks in an XMLP message along an XMLP message path. It acts in order to forward the XMLP message towards the ultimate XMLP receiver.

SOAP

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.

Comparison

no conflict

Proposed Resolution

Introduce the XMLP definition

19 ultimate XMLP receiver

The XMLP receiver that the initial sender specifies as the final destination of the XMLP message within an XMLP message path. An XMLP message may not reach the ultimate recipient because of an XMLP fault generated by an XMLP processor or an XMLP Handler along the XMLP message path.

SOAP

SOAP doesn't call this out explicitly

Comparison

This doesn't conflict with the SOAP model

Proposed Resolution

Introduce the XMLP definition

20 XMLP data model

A set of abstract constructs that can be used to describe common data types and link relationships in data defined by XMLP modules.

SOAP

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

Comparison

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

Proposed Resolution

Introduce the XMLP definition

21 XMLP data encoding

The syntactic representation of data described by the XMLP data model within one or more XMLP blocks in an XMLP message.

SOAP

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

Comparison

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

Proposed Resolution

Introduce the XMLP definition


Henrik Frystyk Nielsen,
@(#) $Id: soap-xmlp-terms-01.html,v 1.3 2001/03/22 19:27:33 frystyk Exp $