RE: Proposal for issue 390

+1 to most of chris's comments.  However, I don't agree with his suggested
change.  My statement "In some cases, it seems likely a move from use of a
resource on the
       web to adding a part to the package could result in a need to modify
       the representation of any reference to that resource."

is accurate. I'm calling out that a SOAP document is a representation.  SOAP
documents may contain references to resources.  Therefore, the reference to
a resource in a SOAP document is actually part of a representation.  So
changing the URIs for an attachment is changing the representation,
specifically the representation of the reference.

Perhaps a clearer statement would be:

        "In some cases, it seems likely a move from use of a resource on the
       web to adding a part to the package could result in a need to modify
       the value of any identifier of that resource."


Cheers,
Dave
  -----Original Message-----
  From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Christopher B Ferris
  Sent: Sunday, October 27, 2002 10:50 AM
  To: Carine Bournez
  Cc: xml-dist-app@w3.org
  Subject: Re: Proposal for issue 390



  Carine,

  Please see below.

  Cheers,

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

  Carine Bournez wrote on 10/27/2002 11:19:55 AM:

  >
  >
  > Issue 390 [0] is part of WSA's review of the AF document.
  >
  > 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."
  >
  > AF doc's introduction [1] partly gives an answer, from an encoding
  > point of view. But at the application level, it seems to be out of scope
  > of this document to provide guidelines about using attachments or not.

  I don't believe the WSA WG was asking for a set of application guidelines
as
  much as some sample generalized use cases that illustrated the motivation
for
  possible applicability of the attachment feature.

  > Usage scenarios would at least depend on the bindings used by the
  > application.
  >
  > 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>. "
  >
  > If a SOAP node is able to do this change it means that it may have good
  > reason to do so (e.g. next node will be unable to resolve the URI), and
it
  > means that this node is aware of the processing capabilities of the next
  > node, in that case it acts as the terminal node and is able to change
the
  > nature of the SOAP message. Also, although the bit-level representation
of
  > http://example.com/Sound.wav and <cid:someidentifierforSoundwav> may not
  > be the same over time. Ie: those two references are NOT the same and
have
  > a different semantic.

  The "semantics" of the resource at a given URI should not change over
time.
  The "state" of a resource MAY change as a function of time. See [1].

  However, this response does not (IMO) address the issue/concern of the WSA
WG.
  We were more concerned with the need to "swizzle" (a new technical term
we've
  coined :-P ) the URI reference within a SOAP message based upon the
possibility that
  the mechanism which implements (binds) the Attachment feature (such as a
binding to
  MIME) might result in the assignment of a new URI (such as in the case of
  the cid:someidentifierforSoundwav example above) that might necessitate
  the modification of the content of the SOAP message should it reference
  the attachment by its URI reference of http://example.com/Sound.wav.

  For example, had the message been signed before it was packaged, changing
the
  URI reference in the SOAP message would invalidate the signature. Had the
SOAP
  message been encrypted, then it might not be possible to change that URI
reference
  at all.

  On further reflection, it would seem that possibly our issue was
misphrased.
  e.g. instead of:
    a..
    b..         "In some cases, it seems likely a move from use of a
resource on the
           web to adding a part to the package could result in a need to
modify
           the representation of any reference to that resource."

  it should probably have been phrased:

          "In some cases, it seems likely a move from use of a resource on
the
         web to adding a part to the package could result in a need to
modify
         the identification of any reference to that resource."
              ^^^^^^^^^^^^^^

  > Based on that, the request would not be the same, which is out of scope
of
  > this document, as it would be defined by the application semantics of
this
  > transformation node.
  > A paragraph about forwarding secondary parts may be added to paragraph 6
  > (implementation) [2] along those lines:
  > "A node should be extremely careful if it decides to retrieve a
  > URI-referenced document and embed it in the secondary part bag, as the
  > semantic of this attachment may no longer be the same."

  I would not recommend adding such a statement. What we were looking for
  was a statement that specifically recommended against changing the URI
  of a secondary part as a function of the implementation of a binding to
  the attachment feature (e.g. in the case of MIME where Content-Id is
  typically assigned as a function of creation of the MIME part). And
  an accompanying statement recommending that any implementation of the
  attachment feature provide a means to associate a given part with
  its original URI identifier (such as with the use of Content-Location
  MIME header).

  >
  >
  > Any comments?
  >
  >
  > [0] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x390
  > [1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/#intro
  > [2] http://www.w3.org/TR/2002/WD-soap12-af-20020814/#implementation
  >
  >
  > --
  > Carine Bournez -+- W3C / INRIA Sophia-Antipolis
  >

  [1] http://www.w3.org/TR/webarch/#persistence