Swizzle words (more on SOAP 1.2 Attachment Feature)

Dave, Chris and Hugo,

To follow up on my action item from today's meeting, here's a few
words.  Thanks especially for Hugo's kind IRC inclusion of the correct
definition for swizzle though I don't think we need to use it directly.

Chris, could you please confirm the presence of the DIME URI features
you mentioned on the call?  I'm not that familiar with the DIME details.

Dave, I left out your mention of a URI to retrieve the content
identifier given a resource URI.  It seems we can avoid that as we avoid
swizzling.  Do you agree?

Existing text for Comment 1:

     The motivation for the usage of URIs for identifying secondary
     parts is incomplete.  It seems apparent for performance and
     other reasons that a part will be a representation of a
     resource.  And packaging will enable higher performance.
     However, if a part is now part of a package and a NEW uri is
     created for the part, that means that any references in a soap
     message ot the resource must change to the NEW uri.  Therefore
     the soap service has to "know" about any and all of the
     contents of the package.  It seems a different approach, of
     providing the original URI and the new URI for the
     representation, would provide the ability for software to keep
     the original URI in the soap message, yet provide identifiers
     for the representation.

     Taking a bit more of a detailed look at this.  Imagine a soap
     element refers to http://myserver/Sound.wav.  My soap
     application now uses some soap attachment feature, perhaps
     DIME.  The representation is now identified by
     mid:someidentifierforSoundwav.  I have to change the soap
     message to use the new URI.  It would seem cleaner if the
     reference stayed the same, and the soap application made some
     API call along the lines of getReference( Ref ) - where Ref
     contains the "http://myserver/Sound.wav" - and the API knew
     that the URI was available in the package.

     Teasing this a bit further, I guess I have a requirement in
     mind something along the lines of "Primary SOAP messages parts
     shall not have to rewrite URIs when they are converted from
     non-attached SOAP messages".  Or another way "SOAP Messages
     References shall be decoupled from whether the referant are in
     packages or not".

New text:

     The motivation for the usage of URIs for identifying secondary
     parts is incomplete.  It seems apparent for performance and
     other reasons that a part will be a representation of a
     resource.  And packaging will enable higher performance.
     [Probably the correct insert location for a request for
     additional motivations for choosing either references to an
     available resource or inclusion in a particular message
     (deciding factors) from Dave.]

     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.  For example, a reference in a SOAP element might be
     "http://myserver/Sound.wav".  My SOAP application now uses
     some SOAP attachment feature, perhaps MIME.  The
     representation is now identified by
     cid:someidentifierforSoundwav.  I have to change the SOAP
     message to use the new URI.  It would seem cleaner if the
     reference stayed the same, and the SOAP application did not
     have to modify these references.

     To avoid this problem, we recommend specifically calling out
     the DIME features allowing an included part to be identified
     using its existing URI.  For MIME, the text should discuss the
     inclusion of a content-location header to server the same
     purpose.  This would allow a recommendation along the lines of
     "applications SHOULD avoid a need to convert references as
     parts are added to a SOAP message."

Hope this helps,
    doug