Mapping XMLP glossary onto SOAP spec

Here is a first mapping of the XMLP glossary [1] onto SOAP/1.1 [2]. The
result is presented in a comparison table [3] where each term is
described as

	* XMLP definition
	* SOAP description/definition
	* comparison
	* proposed resolution

In most cases, the mapping is fairly straight forward. Especially for
the envelope and message constructs where SOAP uses schema to define the
constructs whereas XMLP uses a verbal and slightly more loose

However, there are problems with three terms that don't map well to SOAP
and those are "handler" [4], "block" [5] and to a lesser extend "module"
[6]. Interestingly enough the definitions from the first Working Draft
that we discussed extensively at the second f2f meeting based on Gudge's
draft are a much better match with the SOAP spec.

I therefore propose that we revisit the previous definitions and work
from there in order to merge the glossaries. In the table, I have made
specific proposals that are very close to the previous definitions and
that do map to SOAP/1.1:

* block: 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.

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

* 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 XMLP blocks and one or more XMLP handlers.

This enables us an application to exchange data without it being part of
a module - it can simply be a copyright statement that is to be
exchanged without any protocol involved processing involved. 

Please see the table [3] for more details.



Received on Friday, 23 March 2001 11:50:26 UTC