- 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)