Re: Opaque data, XML, and SOAP

On Friday, February 28, 2003, at 10:01 AM, John J. Barton wrote:

> Ray,
>
>    Sorry I wasn't clear.  I certainly don't believe that XML needs to
> do anything about a universal object model.  I was only agreeing with
> Box et al that mechanisms to work with a mixture of XML and binary
> are not limited to SOAP.

Yes.  I believe that a better general approach would to start with a 
general-purpose envelope capable of holding small modular pieces of XML 
as well as larger and / or more-complex XML, binary, text, etc. that 
cannot be placed into a SOAP-like envelope.  That way you don't wind up 
with one envelope and block / module system nested inside of another.

MIME, for example, is clearly much more reasonable than XML for holding 
arbitrary content, large and small, making it much easier to skip / pass 
through the blocks that your processing node is not interested in.

XML was designed for encoding documents, and as a result, the processing 
tools tend to pull the entire set into memory, and there are undesirable 
interactions, between markup in different parts of the document even if 
these are logically supposed to be separately processed.

>   If I am an application writer and I am writing code to traverse 
> through  the
> data structure returned  by parsing XML, then I will encounter some
> references to non-XML data.  Surely this must be true!  It happens for
> HTML all the time, with references to GIF and JPEG.  I don't know how 
> XML's
> open nature could be violated by referencing non-XML data.  And if the 
> tools
> cannot handle  references to binary then what are they good for?

I never said external references caused a problem.  It was embedded 
binary data, especially large data, which seemed to be advocated 
(referring to the new XML Schema type), that seems to be the big 
problem.  Data embedded in a more-appropriate external envelope is not a 
big problem.  The only question then is why two envelopes -- a leaky 
inefficient one inside a better one.  XML does not make a good envelope 
for modular / independent blocks.  It makes a good container document, 
but that is quite a different thing, where independencies are normal and 
you may expect to carefully parse and interpret it and pull everything 
into memory at once.

>   We should have a standard that allows a sender to combine XML with 
> some
> non-XML data in a way that a receiver can parse the XML and access the
> non-XML data.  It shouldn't matter if the XML is SOAP or not.

I agree.  MIME may be a good candidate, depending upon the exact 
requirements.

It seemed that ebxml was on the right track until they decided to embed 
SOAP, creating, again, the leaky envelope within the envelope effect 
making modular processing more difficult and less efficient and creating 
confusion between the competing roles of the envelopes.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 4 March 2003 09:43:21 UTC