Re: SOAP AF review comment 1 response

I'm not overly thrilled with this response, particularly the second part.

I think that it all boils down to perspective. If you look at a message 
that is
either multipart/related, or application/dime from the outside, then 
clearly,
there is a different semantic from dereferencing a URI to retrieve a 
resource
representation and simply selecting a MIME part or DIME record and 
streaming
its contents.

However, if you look at it from the inside (from the perspective of 
processing
the SOAP message) you stumble across a URI references and you dereference
it to retrieve a representation of the resource identified by that URI. 
Whether it
just happened to be "local" (e.g. packaged with the SOAP message in a 
multipart/related or application/dime encapsulation) or whether it was 
actually
retrieved from the Web, is (or at least I claim it SHOULD be) irrelevant.

IMO, a valid use case not considered in the intro to the SOAP1.2-AF spec
is where I have an XML document containing URI references to resources 
that
are behind my firewall. If the message is sent outside my firewall, the 
resources
that these URIs identify become inaccessible. Hence, a valid approach to 
solving
this problem would be to retrieve the representations and "cache" them 
with the
message that references them. Thus, when the processer that receives the 
message
processes that message it can establish a URIResolver with the MIME or 
DIME 
package as its context. This URIResolver is interposed on any requests to 
dereference
a URI. If the URI is contained in the MIME or DIME package, then the 
part/record that
has that URI as its identifier is returned, otherwise, the request is 
dispatched to the
Web. In either case, the result is the same. The "application" doesn't 
know the difference.
It just dereferenced the URI and retrieved a representation of the 
identified resource.

The same application behind the firewall might not have the representation 
packaged
with the SOAP message, but its processing is identical.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Hugo Haas wrote on 10/30/2002 11:42:31 AM:

> All,
> 
> Attached is the answer of the XML Protocol Working Group to our SOAP
> Attachment Feature review comment 1[1].
> 
> Regards,
> 
> Hugo
> 
>   1. http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390
> -- 
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
> 
> ----- Message from Carine Bournez <carine@w3.org> on Wed, 30 Oct 2002 
17:22:35 +0100 -----
> 
> To:
> 
> hugo@w3.org
> 
> cc:
> 
> xmlp-comments@w3.org
> 
> Subject:
> 
> Closing issue 390
> 
> 
> Hugo,
> 
> You raised issue 390 [0] on behalf of WSA WG.
> 
> The first part of the issue is a general request to explain why and
> when using the attachments (rather than links to resources):
>    " We recommend the XML Protocol Working Group
>     to document the motivations for using the SOAP Attachment Feature,
>     for example with a set of usage scenarios."
> 
> In AF's doc introduction [1], the 3 bullets give use cases of 
attachments
> from a SOAP point of view. An attachment is a particular part of the
> SOAP message. We don't see any further need to give use cases of 
attachment
> along with some particular implementations and particular bindings.
> The attachment feature was designed initially to complete the SOAP 
> specification. 
> 
> The second part of the issue asks clarifications about how resources
> on the web (referenced by a URI) are added as a part (how a change of
> reference is handled):
>    " For example, a
>      reference in a SOAP element might be 
<http://example.com/Sound.wav>.
>      My SOAP application now uses some SOAP attachment feature, perhaps 
>      MIME. The representation is now identified by
>      <cid:someidentifierforSoundwav>. "
> 
> We claim that the semantics is not the same when you refer to an 
external
> URI than when you attach a particular representation of that resource (a
> snapshot). We allow both external and internal reference to 
> a resource, which are different usages, but we do not preclude any.
> 
> Wrt referencing attachment in general, it is a binding problem and not
> an attachment feature issue. It is possible to refer either to external 
> URIs, either to parts of the secondary bag. The way the URI is resolved
> is certainly not in scope of the Attachment feature.
> 
> 
> Please let us know asap if this is not satisfactory. 
> 
> 
> [0] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390
> [1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/#intro
> 
> 
> -- 
> Carine Bournez -+- W3C / INRIA Sophia-Antipolis