RE: Opaque data, XML, and SOAP

At 08:21 AM 3/11/2003 -0500, Eugene Kuznetsov wrote:
> > All we'd need is a "binary" rather than "base64binary" that did not
> > apply base64 to the data.  The base64 bit is only useful for email.
>
>Well, it's not as simple as just no encoding -- you still have to deal
>with the delimeter problem, right? If your binary data contains
>"</foo>", that would be a problem. What you need is an unparsed entity
>of sorts for binary data.

Amy's XML scheme extension for MIME content prefixes the non-XML content
with a content-length.  No delimiters needed, hence no delimiter problem.

>
>
> > to outweigh the
> > interoperability / backwards incompatibility costs, preferably with
> > realistic use cases as actual performance/bandwidth data.
>
>Mike, where/to-whom would one submit these? Just the business of
>optimizing handling of arbitrary-length element and attribute names can
>keep someone quite busy for a while, multi-megabyte base64 sections will
>not be a good thing.
>
>Interestingly, all the discussion focus here is on the on-the-wire
>encoding issues -- doesn't seem that anyone feels strongly that binary
>data should be passed by reference in some external envelope?

On the contrary, I still believe that a layered message stack  for mixing
XML and non-XML data is a better design:

        Application         e.g
       Control/Data          XML/MIME-types
       Packaging            e.g. SwA
       Transfer               HTTP
       Transport             TCP/IP

(BTW RFC1341 makes a pretty good case for this design). This
model leads to XML referencing entities in the package.
Such a model separates the tool set for packaging from the tool set
for application data, allowing each to be optimized for their task and
ignorant of the detail of the other one. Tool-set developers, of course,
prefer their tool to be used for the entire stack.

In some recent mail we have been exploring alternatives that
embed the binary in the XML, eliminating the packaging layer.
I still believe that this is a technically inferior solution for
large systems, but if its the only one that we can agree on I'd
like to see if we can minimize the damage ;-)

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Tuesday, 11 March 2003 13:22:37 UTC