RE: Opaque data, XML, and SOAP

Don,

I am new to SOAP, but in the last week I discovered this issue.  Now I 
find you are already arguing the case for me.  I agree with you 
completely.

Ken



Date: Tue, 11 Mar 2003 11:23:44 -0800
Message-ID: 
<57EF69AF56D92148984EDA317408294504536596@RED-MSG-10.redmond.corp.microsoft.com>
From: "Don Box" <dbox@microsoft.com>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>, "Martin Gudgin" <
mgudgin@microsoft.com>
Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <
xml-dist-app@w3.org>
Subject: RE: Opaque data, XML, and SOAP


> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM]
> Sent: Tuesday, March 11, 2003 9:13 AM
> To: Martin Gudgin
> Cc: Champion, Mike; xml-dist-app@w3.org
> 
> 
> On Tuesday, Mar 11, 2003, at 11:36 US/Eastern, Martin Gudgin wrote:
> >>
> >>> What is obvious to me is that the infoset is a very poor place to
> >>> carry  large binary data.
> >>
> >> Hmmm.  I tend to agree, but it probably depends on what
> >> "large" means in a particular context. I'll guess that what
> >> we need are well-specified mechanisms that would allow
> >> systems designers to *either* carry reasonably-sized binary
> >> data along with the infoset when that is appropriate, or to
> >> attach references to unreasonably sized binary data for the
> >> situations where embedding it in the infoset is
> >> inappropriate.
> >
> > Given that the Infoset is an abstraction, rather than a
serialization,
> > what does 'embedding it in the infoset' mean?
> >
> +1. IMO we need a standard mechanism for 'abstractly including' binary
> data in an infoset. By 'abstractly including' I mean that the data is
> included in an abstract sense rather than included literally as CIIs.
> 'Binary smart' processing can take account of the abstract inclusion,
> existing processing can ignore it.

Bingo. I want to use my XML-based schema languages to describe how
binary works in my message. Please don't make me invent another schema
language for describing messages (a la WSDL/1.1 Section 5).

> In practice this would probably take the form of a standard reference
> mechanism within the SOAP message and an external MIME envelope to
hold
> the SOAP message and (none, some or all of) the associated binary data
> (the none/some cases allowing for external references to support the
> portable cache metaphor). If required, the reference could be flexible
> enough to allow inlining using a suitable encoding.

+1. And of course, for completely low-functioning
receivers/intermediaries, one could if desired drop down to pure XML 1.0
and base64.

I think people underestimate the impact of having two data models when
considering intermediaries (or the SOAP stacks in ultimate receivers)
that are ignorant of SwA/WS-Attachments/DIME.

DB