- From: Bob Cunnings <cunnings@lectrosonics.com>
- Date: Sat, 12 May 2001 09:28:00 -0700
- To: xml-dist-app@w3.org
Hello, 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. RC
Received on Saturday, 12 May 2001 11:28:26 UTC