RE: ebXML Abandons SOAP

> I have to wonder if it makes sense to have protocol that
> tries to be all (5)
> things to all people. SOAP seems great for RPC, method calls
> and passing
> data types, but since it doesn't nicely hold binary or even
> XML documents
> (and I said nicely) then ought it really be a candidate for
> all 5 choices in
> Mike's survey? Ought it really be the candidate for passing
> XML documents?

I don't see why being able to transfer binary and/or xml data within a
message has much do with what the message is being used for. In other
words, whether the message is being used for messaging or RPC or whatever
seems to me to be orthogonal to the question of how to embed binary and
xml data within a message.

SOAP allows for two mechanisms for carrying data: By value and by
reference (using href) and it would seem a natural fit to use by reference
when dealing with data that doesn't fit "nicely" (for whatever reason).
Depending on the
scenario and the property of the data, URI can be something like
"http:..." or "cid:..." (for MIME multipart) or something else entirely. I
know that John J. Barton, Hewlett Packard Labs and Satish Thatte,
Microsoft have been working on the MIME multipart scenario.

> I am hoping (and maybe I haven't read enough of the charter)
> that the "XML
> Protocol" working group will create "a good protocol for
> passing XML" (and
> not having to base64 encode it.) Since CDATA can't contain
> CDATA, since XML
> can't easily contain XML, it doesn't seem that XML (as is
> today) is a good
> carrier/envelope for XML. As such -- is SOAP right for an XML
> Protocol?

The purpose of the SOAP message is to provide a consistent and
well-defined processing model for the whole message and to allow for a
rich composability model where features can live side by side in the same
message without stepping on each other. This is the reason for the
definition of the term "SOAP processor". Doing this for XML in anything
but XML would be extremely difficult unless the data model is the same as
for XML in which case we might as well use XML in the first place.

Henrik

Received on Monday, 2 October 2000 18:54:43 UTC