SOAP provides what isn't necessary:

- the <SerializedStream> wrapper
    ==> once the client has checked the Schema of the server using my "XML All-purpose Protocol" proposal, there is no need for such a wrapper, the client will directly use the vocabulary of the server

- the <__return> wrapper
 ==> I don't think that an XML protocol has to mimic a function call like XML-RPC and SOAP; the distinction beetwen function and procedure is allready questionable for programming languages, but for an XML protocol is it something that belongs to the servers's schema.

- the Response construct is really ugly; for readers that have not read the SOAP spec.: if the client has sent a tag <PlaceOrder>, the server must use a tag <PlaceOrderResponse>
==> besides being syntactically ugly, the principle is  that the response vocabulary is freely specified by the server 

SOAP doesn't provides what IS necessary:

- freedom to specify Schemas in any way (of course XML Schema is the natural choice)
==> SOAP is still using XML-data of 1998 for datatypes

- M-POST verb for HTTP
==> no rationale is provided for this

- mustUnderstand boolean attribute
==> again, no need to specify this in the general case, because with XML Schema the server can specify with great accuracy the possible query variants; it is clear that if the client doesn't comply with the server's schema, it is pointless to insist with a "mustUnderstand" statement, and if the  client does comply it is obvious.

The following item is valuable but seems misplaced:

- transactionID
==> should be attributed by the server the first time it encounters a client, and afterwards should be re-sent by both (except of course if the client wishes a new session)
  new session)