- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Fri, 19 Aug 2005 13:59:07 -0700
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: "Costello,Roger L." <COSTELLO@mitre.org>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
Right; I said 'pretty much' because although you can put anything in base64binary, at a "schema level" it surfaces as base64binary. I think the problem here is when people think that Schema defines the complete data model (which is really almost never possible). Cheers, On 19/08/2005, at 1:28 PM, Marc Hadley wrote: > I agree with Noah's comments. The base64 thing is sort of > confusing, its only there as a notional representation of the > actual binary data so that it can be logically included as part of > the SOAP message XML infoset. > > In reality, base64 never actually needs to be materialized unless > you are using something like WS-Security to sign the message contents. > > Marc. > > On Aug 19, 2005, at 3:14 PM, noah_mendelsohn@us.ibm.com wrote: > > >> >> Mark Nottingham writes: >> >> >> >>> (quoting Roger Costello) >>> >>> b. XOP seems to be usable only with base64Binary >>> >>> >>>> data, whereas my impression is that SOAP with >>>> attachments is general purpose (i.e., the >>>> attachment can be any non-XML file, not just >>>> base64Binary data). Is this a correct >>>> statement? >>>> >>>> >>> >>> Pretty much, although you can use SwA with an XML >>> file as well. The WG decided to keep XOP >>> base64Binary-only to keep it simple. >>> >>> >> >> I have a slightly different interpretation. I would claim that the >> purpose of both SWA and XOP/MTOM is to convey in conjunction with >> a SOAP >> message zero or more binary streams, typically typed with MIME media >> types. Either can be used to send, for example, an image/jpeg, >> and in >> both cases the intended wire format is also binary as opposed to >> base64. >> The difference is that in the case of XOP, there is an Infoset-level >> abstract model that establishes an equivalence between each such >> serialized form and an XML 1.0 infoset; in that infoset the >> content is >> indeed represented as base64. Typical implementations will >> construct this >> base64 character form only if needed to interact with non-MTOM/XOP- >> aware >> software or systems. I suspect that's what Mark meant when he said >> "pretty much", but it's an important point. I therefore don't >> agree that >> "XOP seems to be usable only with base64Binary data". I'd say XOP >> provides mappings to base64Binary to facilitate interoperation with >> systems that don't support XOP. >> >> Also, I would strongly urge against using QNames such as >> xop:include in a >> context not licensed by their normative specifications. >> xop:include is >> specified for use in XOP. If someone wishes to establish a XOP- or >> probably MTOM-aware binding for SOAP 1.1, then that makes good sense >> technically. I would look to organizations like ws-i.org to decide >> whether such a development is a good basis for industry-wide >> interoperation. >> >> Noah >> >> -------------------------------------- >> Noah Mendelsohn >> IBM Corporation >> One Rogers Street >> Cambridge, MA 02142 >> 1-617-693-4036 >> -------------------------------------- >> >> >> >> >> >> >> >> >> Mark Nottingham <mark.nottingham@bea.com> >> Sent by: xml-dist-app-request@w3.org >> 08/19/2005 01:49 PM >> >> To: "Costello,Roger L." <COSTELLO@mitre.org> >> cc: <xml-dist-app@w3.org>, (bcc: Noah >> Mendelsohn/Cambridge/IBM) >> Subject: Re: XOP compatible with SOAP 1.1 processors? >> >> >> >> Roger, >> >> On 19/08/2005, at 8:34 AM, Costello,Roger L. wrote: >> >> >> >>> a. Since SOAP 1.1 doesn't care what XML tag is used, then I might as >>> well just use the standard XOP Include tag, right? That way, I can >>> use >>> a SOAP 1.1 processor, but take advantage of a SOAP 1.2 capability. >>> Or, >>> is XOP somehow incompatible with SOAP 1.1 processors? >>> >>> >> >> XOP is a generic, alternate serialisation of the XML Infoset. MTOM is >> the binding of XOP into SOAP 1.2. To use XOP in SOAP 1.1, you'd need >> something similar to MTOM for it. There isn't any technical barrier, >> it's just a matter of getting it specified. >> >> >> >>> b. XOP seems to be usable only with base64Binary data, whereas my >>> impression is that SOAP with attachments is general purpose >>> (i.e., the >>> attachment can be any non-XML file, not just base64Binary data). Is >>> this a correct statement? >>> >>> >> >> Pretty much, although you can use SwA with an XML file as well. The >> WG decided to keep XOP base64Binary-only to keep it simple. >> >> >> >>> c. Would it be reasonable for me to make this recommendation to my >>> clients: when using SOAP 1.1 and the attachment is a base64Binary >>> file >>> then use the standard XOP Include tag to reference the >>> (base64Binary) >>> attachment? >>> >>> >> >> They probably won't get good interop on that. >> >> Cheers, >> >> -- >> Mark Nottingham Principal Technologist >> Office of the CTO BEA Systems >> >> >> >> >> >> >> > > --- > Marc Hadley <marc.hadley at sun.com> > Business Alliances, CTO Office, Sun Microsystems. > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Received on Friday, 19 August 2005 21:00:26 UTC