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