mlw wrote:
> I think you are interpreting the spec a bit too restrictively. The
> syntax is fairly rigid, but the spec has a great degree of flexibility.
> I agree that, syntactically, it must work through a parser, but there is
> lots of room to be flexible.
This is /exactly/ the standard problem with SOAP.
There is enough "flexibility" that there are differing approaches
associated, generally speaking, with "IBM versus Microsoft" whereby it's
easy to generate SOAP requests that work fine with one that break with
the other.
For a pretty simple example of a longstanding bug that has never been
fixed, see:
<http://sourceforge.net/tracker/index.php?func=detail&aid=559324&group_id=26590&atid=387667>
The precis:
The SOAP implementation used by the XMethods folks to publish stock
prices is buggy, rejecting perfectly legitimate messages submitted using
ZSI (a Python SOAP implementation).
The bug isn't with ZSI; it is quite clearly with the server, apparently
implemented in Java using one of the EJB frameworks.
In practice, what happens is that since that service is fairly popular,
particularly for sample applications, the implementors of SOAP libraries
wind up coding around the bugs.
The problem is that it gets difficult to tell the difference between
bugs and variations in interpretations of the standards.
If the specs were more strictly defined, it would be a lot easier to use
SOAP, because you wouldn't be left puzzling over whether the
interoperability problems you're having are:
a) Problems with the client;b) Problems with the server;c) Problems with interpretation of specs;d) ...
The vast degree to which messages can get rewritten behind your back
adds to the fun.
Of course, it's only fun if you *enjoy* having interoperability
problems...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/soap.html
He who laughs last thinks slowest.
