RE: Proposal for issue 390

Yes, I think we're saying the same thing. Bottom line, if the reference in 
the SOAP
message needs to be changed to accomodate a change in the value of the
identifier used to identify the referenced resource (attachment) that 
would
not be "a good thing(tm)".

Cheers,

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

David Orchard wrote on 10/28/2002 10:06:26 PM:

> +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: 
>         "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