-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Elliote,
> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:]
>
> Anybody still listening to this thread?
>
> This was a big can of worms that unexpectedly popped open at the
> SD2002 SOAP BOF last week. Some participants were adamant that
> they needed to consider and act on the envelope irrespective of
> the
> contents of the body, even if the body was malformed. For
> example, they wanted to be able to do forwarding and error
> reporting rather than just dropping the malformed message on the
> floor.
>
> If they're right, and this is a common need, then I have to say,
> as I did then and there, that SOAP is fundamentally flawed, and
> cannot be repaired. The requirement to mix envelope and body in
> a single XML document is irreconcilable with the need to process
> the envelope independently of the body. Thus we pound one more
> nail into SOAP's coffin.
>
> Interestingly, XML-RPC does not share this problem since it does
> not have an envelope.
The envelope is somewhat incidental. The problem is the payload
(aka SOAP body) is not opaque wrt to its envelope. If you want an
enveloped messaging model to work out well, your payload should not
be a structural extension of your envelope. Otherwise, in the SOAP
case it implies a body it must well formed, ie parsable. It also
implies you need to parse the body just to get at the headers.
Requiring that the body be walkable by any actor other than the
recipient, is fully random. The fact that SOAP messages aren't
properly recursive is the big clue here. I mentioned (nearly a year
ago now) on xml-dist app that making the body a special type of
header was unfortunate. Not for the reason mentioned, but that by
throwing this coupling away you wouldn't require a SOAPAction to
know something about the message. SOAPAction is hack to avoid
parsing the XML; we avoid parsing the XML because the body has to
be parsed as well. Nary a response as I recall.
Multipart MIME got this right (make it multipart!), XML-RPC got
this right (don't use an envelope), FIPA Abstract Architecture got
this right binding (use an envelope, but make the payload opaque),
as did its HTTP message binding (use a multipart mime
serialization).
One possible solution: shred the headers and body into 2 documents
and make SOAP multipart. We have the guts of a spec to do this;
SOAP with attachments. That is, all SOAP messages become SOAP with
an attachment, where the default attachment is the SOAP body and
only the recipient cares about looking inside it. SOAPAction could
be thrown away as well for good measure.
Bill de hÓra
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPM0cyeaWiFwg2CH4EQIkAQCghmcFlf2mISpgWQSavZxH9g19tuQAnRZU
VvaZqX4dchBZfCskn1ZUEeEV
=BWyu
-----END PGP SIGNATURE-----
