[R505][i54] No a priori knowledge Requirement

XML Protocol Requirement R505 [1] states

"The specification must be suitable for use between communicating parties 
that do not have a priori knowledge of each other."

Whether or not SOAP 1.2 meets this requirement is Issue 54 [2].

This requirement is derived from the XMLP WG charter [3],

"Focus must be put on simplicity and modularity and must support the kind 
of extensibility actually seen on the Web. In particular, it must support 
distributed extensibility where the communicating parties do not have a 
priori knowledge of each other."

and is also stated in the WSAWG charter [4],

"In particular, it must support distributed extensibility, without third 
party agreement, where the communicating parties do not have a priori 
knowledge of each other."

I would like give you my interpretation of what this means, and ask you to 
comment if you have a different view.

In my view, "Communicating parties" refers to the applications that make 
use of a SOAP processor at a SOAP node.  The lack of a priori knowledge by 
the communicating parties refers to a degree of transparency about the 
underlying mechanisms used to transfer a SOAP envelope.  It relates to the 
concept of layering, and separation of interface from implementation, where 
higher layers make use of an interface to lower layer mechanisms rather 
than duplicate the functions of those lower layer mechanisms.

SOAP 1.2 does not define an API, but there is the notion of a SOAP 
processor distinct from the application.  The binding framework allows for 
different bindings, two or more of which implement the same message 
exchange pattern (MEP).  Therefore, an application may be designed to rely 
on a particular MEP, but would not care which binding is used to actually 
transfer the message; they would be transparent to the application.

The WSAWG charter's clause about "without third party agreement" gives us a 
clue of the concern about a priori knowledge.  An example of a third party 
agreement would be if new SOAP features (SOAP header block namespaces, 
bindings, message exchange patterns, encoding styles, and fault codes) 
could not be used unless W3C approved them.  This is NOT the case.  No W3C 
approval is needed to define such new features.  Definition of such new 
features without W3C knowledge will not necessarily break the compliance 
with the SOAP 1.2 specification.

One possible area where third party agreement may be needed is for the 
application/soap+xml media type [5] for the HTTP binding, which  should be 
approved by the IETF.

If we consider the applications to be the "communicating parties", then it 
is not a requirement that the SOAP processor not have some a priori 
knowledge.  The SOAP processor may have a priori configuration data about 
communicating parties, for example, to route messages to a particular SOAP 
intermediary.  This is similar to a web browser preferences-setting for an 
HTTP proxy; the user may not be aware that the HTTP requests are passing 
through the proxy.

Other examples where a communicating party would not need a priori 
knowledge would be by using a runtime discovery mechanism, such as 
UDDI.  Certainly SOAP 1.2 does not preclude using such as discovery mechanism.

SOAP faults are another way of dealing with a lack of a priori 
knowledge.  If a sender includes a SOAP header block marked with 
mustUnderstand="true", a fault is generated if the receiver does not 
understand it.  The sender can respond to the fault by trying to send the 
message with a different SOAP header.  The sender gathers the knowledge at 
runtime.  Although SOAP 1.2 does not define an explicit negotiation 
sequence, use of SOAP faults and SOAP headers provide the extension 
mechanisms that can be used to define a new SOAP feature for negotiation.

The notion of a contract seems to imply some a priori knowledge.  However, 
this can be a priori knowledge about the contract, and not necessarily a 
priori knowledge about the communicating parties.  That is, the contract 
could be knowing whether or not you implement a particular SOAP 
feature.  If you received a SOAP header block implementing that feature, 
you would not generate a mustUnderstand fault.  You don't necessarily know 
ahead of time what communicating parties would send that header 
block.  Obviously, you may have installed that feature as a result of a 
priori knowledge that some communicating parties would want to use it.

Based on the discussion above, I assert that the SOAP 1.2 specifications 
meet the spirit of requirement R505 [1], and we can close issue 54 [2].

However, since this requirement appears to be a matter for the WSAWG [4], I 
recommend that the concepts surrounding a priori knowledge be examined by 
the WSAWG.  The XMLP WG can open a new issue if the WSAWG determines that 
SOAP needs to address some aspect of it.

[1] http://www.w3.org/TR/xmlp-reqs#z505
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x54
[3] http://www.w3.org/2000/09/XML-Protocol-Charter#scope
[4] http://www.w3.org/2002/01/ws-arch-charter#arch
[5] http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt
[6] http://www.ietf.org/rfc/rfc2048.txt

Paul

Received on Saturday, 9 March 2002 09:57:05 UTC