RE: SOAP AF review comment 1 response

I totally concur with ChrisF.  And this fictional URIResolver is exactly
what we were thinking of how the issue of references would be dealt with.

Cheers,
Dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Christopher B Ferris
  Sent: Wednesday, October 30, 2002 9:42 AM
  To: Hugo Haas
  Cc: www-ws-arch@w3.org
  Subject: 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

Received on Wednesday, 30 October 2002 14:05:37 UTC