Re: SOAP AF review comment 1 response

David and Hugo,

I also concur with Chris and David.

What is the procedure we need to follow when providing additional 
feedback on an unsatisfactory closure of a last call issue?

thanx,
    doug

David Orchard wrote:

> 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: [email protected]
>     [mailto:[email protected]]On Behalf Of Christopher B Ferris
>     Sent: Wednesday, October 30, 2002 9:42 AM
>     To: Hugo Haas
>     Cc: [email protected]
>     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: [email protected]
>     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:[email protected] - http://www.w3.org/People/Hugo/
>     >
>     > ----- Message from Carine Bournez <[email protected]> on Wed, 30 Oct
>     2002 17:22:35 +0100 -----
>     >
>     > To:
>     >
>     > [email protected]
>     >
>     > cc:
>     >
>     > [email protected]
>     >
>     > 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  
>