W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2000

RE: ebXML Abandons SOAP

From: Michael Brennan <Michael_Brennan@Allegis.com>
Date: Mon, 2 Oct 2000 18:08:32 -0700
Message-ID: <753B28EF1C2DD411AF1C00B0D0202CB556A277@mailhost.hq.allegis.com>
To: xml-dist-app@w3.org
> To me this is simple: XML (today) just isn't a good XML 
> envelope, but it is
> good for extensibility of headers, and as a message body 
> part. 

It's a great envelope for structured data, which is likely to be the most
common content sent via XML-based messaging schemes. For unstructured data,
it provides no value, but base64-encoded data sent in an XML message is no
worse than base64-encoded data sent in a MIME message.

When using "8-bit clean" transport protocols such as HTTP, one can send
binary data in a MIME message without having to resort to encoding. For this
purpose, I think an approach like the "SOAP With Attachments" proposal makes
sense, and should probably be supported as an option by XP. I don't think it
has to be an "either/or" proposition.

> Why make us
> mess around with encodings when a simple enveloping mechanism 
> would remove
> the need, keep it simple, and still have it extensible.

If you are referring to SOAP-Encoding, note that the SOAP spec itself does
not require (or even recommend) SOAP-Encoding. It is simply specified in the
spec as an option. I think once XML-Schema is finalized and we have some
decent data-binding tools on the market, SOAP-Encoding will be less
significant. Of course, this may run against the "keep it simple" notion,
but I think it is an inevitable course and will provide great value. 

If you are referring to encodings in general, there's no way around it.
Different platforms have different binary representations for the same data.
You can't send text or data and expect the receiving end to understand
unless both ends agree upon a defined set of supported encodings and both
ends can unambiguously identify the specific encoding used for the
transmission. That's why we have media types; that's why we have "charset"
parameters in "Content-Type" headers that use official IANA registered
names; that's we have the "encoding" attribute in the XML declaration
specified by the XML 1.0 spec. It's an unavoidable topic. When you are
dealing with structured data, the encoding rules need to go down to the
level of individual data items; you can't stop at the message level.
Received on Monday, 2 October 2000 21:17:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:10 UTC