RE: Opaque data, XML, and SOAP

+1 to John's points.

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

xml-dist-app-request@w3.org wrote on 03/11/2003 01:22:33 PM:

> 
> 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
>