- From: Don Box <dbox@microsoft.com>
- Date: Tue, 11 Mar 2003 11:23:44 -0800
- 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>
> -----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
Received on Wednesday, 12 March 2003 12:09:02 UTC