W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2002

Re: Comments on SOAP 1.2 Attachment Feature

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 10 Sep 2002 11:47:49 -0400
To: "Christopher B Ferris" <chrisfer@us.ibm.com>
Cc: Marc Hadley <marc.hadley@sun.com>, "Herve Ruellan" <ruellan@crf.canon.fr>, xml-dist-app@w3.org
Message-ID: <OFCC9DBA1F.8780AB6B-ON85256C30.00562A93@lotus.com>

Chris Ferris suggests:

>> I suppose that this could be interpreted in a couple of ways: 
>> 
>> 1) that the binding layer assigns the URIs for its
>>    purpose that can be mapped to the URIs that identify
>>    the parts in the compound SOAP structure such that the
>>    infoset representing the compound SOAP structure can be
>>    faithfully transferred from sending node to receiving
>>    node.
>> 
>> 2) that the application assigns the URIs based on some
>>    knowledge of the scheme(s) supported by the binding.

I think these are implementation decisions outside the
scope of our specifications.  I think we say in each
binding spec: "a correctly formed transmission of an
envelope plus attachments looks like this".  In other
words, it's got certain URIs, is packaged in the
transport in a certain way, etc.  How your code puts
that together is completely up to you, and not visible
from the outside.  I write software where the app asks
the binding, you write software where the app tells the
binding.  If both put conformant bits on the wire, we're
OK.  Of course, this doesn't help you throw out my Java
code so that you can swap in yours, but that's never the
job of the SOAP spec.  Implementation-specific standards
(e.g. Java API standards for creating attachments) can
be established by others, if desired, to solve this problem.

Many thanks.

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Tuesday, 10 September 2002 11:51:45 GMT

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