Re: SOAP 1.2 Attachment Feature review

Hugo,

My apologies for not having the context of reading the reviewed specification
;-)  With that grain of salt...

When reading comment 1, I immediately think of the MIME content-location header
and its use in exactly this situation.  Some efficiency may be lost through
having to fall back to retrieving from the URI when not present in the message
rather than immediately knowing a GET (for example) is necessary.  However, the
manifest information provided in the SOAP envelope or other payloads does not
need to change.  This might have a different solution (such as your proposed
"API") when using DIME.

I would probably extend the current motivations to mention "caching versus
single source" performance arguments.  When the payload is available externally
to the message and retrievable using a GET (again, for example), it may be
cached.  When everything is available in the received message, the application
has everything it needs immediately to begin processing.  Improved latency
either way, depending upon the cache hit ratio?

Separately, I believe Dave should have said "cid:someidentifierforSoundwav".
The URI identifies a part of the current message, not a distinct message or this
(current) entire message.

thanx,
    doug

Hugo Haas wrote:

> Below is a proposed answer to the XML Protocol Working Group is as
> follows, merging Mark's and Dave's comments with mine.
>
> In light of Dave's comment, I have replaced my first comment by his.
>
> Regards,
>
> Hugo
>
>   -------------------------------------------------------------------
>
> Comment 1
> ---------
>
> The motivation for the usage of URIs for identifying secondary parts is
> incomplete.  It seems appararent 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".

...

Received on Wednesday, 16 October 2002 17:18:02 UTC