- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 19 Aug 2005 15:14:08 -0400
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: "Costello,Roger L." <COSTELLO@mitre.org>, xml-dist-app@w3.org
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
Received on Friday, 19 August 2005 19:14:30 UTC