RE: proposed response to XMLP response to issue #390

It seems to me that the "not satisfied" is probably OK but sort of at
the edge.  I personally would have tried something along the lines of 
"The WSAWG has considered the XMLP WG's response to issue #390 and we
still have concerns.  We would like to request that the XMLP WG reopen
issue #390 to address these concerns."
 
Maybe that's too wussie, and as I said I think "not satisfied" will make
the grade.
 
Well, how about, "The WSAWG has considered the XMLP WG's response to
issue #390 and we still are not satisfied for the reasons detailed
below.  We would like to request ..."?  That keeps the strong term but
adds some human engineering stuff sort of hinting that we tried to look
at it from their point of view, or something like that. 
 
-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Monday, December 09, 2002 9:02 AM
To: www-ws-arch@w3.org
Subject: proposed response to XMLP response to issue #390



Following the telcon last week, here is the proposed response to the
XMLP WG 

<proposed response>
The WSAWG is not satisfied with the XMLP WG's response[2] to issue
#390[1] 
and would like to request the XMLP WG to reopen issue #390.

We believe that this issue involves a matter of perspective. 

A message that is either MIME multipart/related, or application/dime,
when viewed 
from the outside clearly has a different semantic from dereferencing a
URI to retrieve 
a resource representation and simply selecting a MIME part or DIME
record and 
processing its contents. 

However, when viewed from the inside (from the perspective of processing

the SOAP message part) the processing of a SOAP message that contains 
a URI reference should not be dependent upon whether the "resource" is 
packaged locally in a MIME or DIME part of the messsage or retrieved
from 
the Web. 

We are of the opinion that dereferencing that URI to retrieve a
representation 
of the resource identified by that URI should be a function of the
binding.

We believe that the following use case has not been considered in the
intro to 
the SOAP1.2-AF spec: 

     A SOAP message that contains URI references to resources that 
     are behind a firewall needs to be sent outside that firewall. 

      A valid approach to solving this problem would be to retrieve the 
      representations and "cache" them with the message that references
them 
      in a multipart/related or application/dime package. 
      The processer that receives the message can establish a
URIResolver with 
      the MIME or DIME package as its context. This URIResolver can be
interposed 
      on any requests to dereference a URI by the SOAP application. 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 SOAP application does not, and need not, know the details of
how the representation 
      was dereferenced. It just dereferences the URI and receives a
representation of the 
      identified resource. 

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

In the context of this use case, the MIME or DIME packaging can be
thought of as a portable 
cache for the retrieved representation. In many if not most cases, we
believe that the use of "attachments" 
is an optimization of processing that might just as effectively be
performed by dereferencing URIs on the 
Web. 

Consider the encoding of an HTML page that includes <IMG src="..."/>
tags being sent in an email. 
Typically, the images can be marshalled into a multipart/related package
along with the HTML 
such that the receiving MUA can view the HTML page along with the images
that it references. 
The MUA that receives the message can view the HTML page as if it were
"on the Web"... the fact that 
the images had been marshalled is irrelevant as it should be and does
not change the processing of 
the HTML, nor does it change the URI's of the images within the HTML
markup. 

We understand that the XMLP WG is undertaking an effort to provide a
concrete binding(s) for the 
abstract Attachment feature, we would ask that the XMLP WG take this
issue into consideration 
when it does so.
</proposed response> 

Comments? 

[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390 
[2] http://lists.w3.org/Archives/Public/xmlp-comments/2002Oct/0046.html 


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