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

Re: XOP compatible with SOAP 1.1 processors?

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Fri, 19 Aug 2005 13:59:07 -0700
Message-Id: <16003737-26D6-443F-9913-FBF3F825854B@bea.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>
To: Marc Hadley <Marc.Hadley@Sun.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 GMT

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