W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

Re: An analysis of mustUnderstand and related issues

From: Bob Cunnings <cunnings@lectrosonics.com>
Date: Sat, 12 May 2001 09:28:00 -0700
To: xml-dist-app@w3.org
Message-ID: <3AFD0220.2648.4D6F5712@localhost>

An excellent analysis.

Regarding the Design Proposal "Ensuring that essential processing
occurs, and in an appropriate order", you mention the 3 most 
commonly offered approaches to providing the required facilities:

1) Built as enhancements to SOAP itself...

2) Built as separate modules, using only existing facilities of SOAP 
1.1 (i.e. Headers and mustUnderstand)...

3) Provided in an application specific manner...

As one who had to develop a SOAP 1.1 implementation which 
supports Header processing and intermediary functionality, I have 
wrestled with the the problem at length and come to the conclusion 
that option 2 is preferable.

I feel strongly that issues like this are application design matters 
and are properly addressed in a "module" whose use is optional. 
The module would completely encapsulate the necessary facilities, 
which will be rather complex.

I believe that building these facilities into the SOAP core will result 
in unnecessary implementation complexity. Further, once done, 
everyone is stuck with the same solution, whatever its merits or 
defects, in perpetuity. Modules, on the other hand, would be easier 
to tailor for specific requirements. It would be no calamity to define 
a "standard" module to solve the problem, but allow app designers 
to freedom to substitute a different solution if necessary.

The facilities in question will not be universally required anyway, 
suggesting again that a standard module, used only when needed, 
is a wiser choice. The "Proposal" contains a design which certainly 
provides a valuable facility for applications that need it. However, I 
think such facilities would be best implemented as modules.

Received on Saturday, 12 May 2001 11:28:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC