Toss section 5 (create SOAP-lite)

Hi Folks,

Some thoughts, no doubt naive, about SOAP as I come up to speed on this
technology.

It is my considered opinion that section 5 of the spec (SOAP Encoding)
should be discarded.  At the bottom of this message I list the reasons. 
However, prior to that I would like to provide the context for my
reasons.

First, I would like to consider what are the "Essentials of SOAP" from
the perspective of the Client wishing to send a message to a Receiver.

Client 
 
  - Creates an XML document (message document) that 
    conforms to a "message XML Schema" (defined by
    the Receiver).
  - Wraps the message document in a SOAP envelope.
  - Schema-validates the wrapped XML document against 
    two schemas: the SOAP schema and the message schema.
  - Hands the wrapped message XML document off to a 
    "SOAP client" to send to the Receiver.

Receiver

   - A "SOAP server" receives the XML document.
   - It removes the envelope.
   - It determines the nature of the message by looking 
     at the message's root element.
   - It hands the message XML document to an 
     appropriate handler.

There are two things to note: 

1. What an "appropriate handler" does with the message is irrelevant.
Likewise, ...
2. How the Client creates the "message document" is irrelevant, e.g., it
could be created by hand using an XML editor, generated by a program,
etc.

Section 5 of the SOAP spec is a long, complex description of how an
"application" is to create (encode) a message document.  Why is it
necessary for SOAP to specify this?  How an application generates a
message XML document is outside SOAP's domain (or, should be, IMHO).
What's important is that the Client generates an instance document that
conforms to an XML Schema which the Receiver has defined.  This schema
represents the "contract" between the Client and Receiver.

Thus, it is my belief that section 5 should be tossed, for the following
reasons:

1. It's irrelevant.
2. It makes SOAP implementations unnecessarily complex.
3. It makes the SOAP technology more difficult to understand and use.
And most importantly, ...
4. It forces focus on a "technical non-issue", whereas users of SOAP
should instead be focused on operational issues, i.e., defining a good
contract (schema).

My 2 cents.  /Roger

Received on Monday, 30 July 2001 16:49:04 UTC