W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2005

Re: XOP compatible with SOAP 1.1 processors?

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
Message-ID: <OF5D9C5937.2C54D1C8-ON85257062.0069821F-85257062.0069AA6F@lotus.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:20 GMT