RE: SOAP 1.2 Attachment Feature review

Here are my comments:

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".

Hugo: on your comment #1, a part that has a base uri and a relative URI is
still only identified by a single URI.  URIs cannot be relative - only URI
references can be.  Fancy specese footwork, but there it is.

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hugo Haas
> Sent: Wednesday, October 02, 2002 1:28 AM
> To: www-ws-arch@w3.org
> Subject: SOAP 1.2 Attachment Feature review
>
>
>
> As per my action item, I have reviewed the 24 September 2002 Last Call
> Working Draft of the SOAP 1.2 Attachment Feature[1].
>
> In a few words, the document specifies an abstract model for modeling
> "attachments" (synonym for secondary part, object, thing, etc) along
> with a SOAP envelope, how to reference those "attachments" from the
> envelope, and what is expected from a binding which support this SOAP
> feature.
>
> FWIW, I prefer the term secondary part and find attachment confusing,
> because I really picture an attachment traveling along with the SOAP
> envelope, like when sending an email with MIME attachments, whereas it
> is not required for the envelope and the secondary parts to travel
> together, e.g. see comment 2.
>
> Comment 1:
> ==========
>
> The specification emphasizes in several places that a secondary part
> may be identified by multiple URIs. Here is the justification:
>
> | Note: the ability to identify a single part with multiple URIs is
> | provided because, in general, the Web architecture allows such
> | multiple names for a single resource. It is anticipated that most
> | bindings will name each part with a single URI, and through the
> | use of base URIs, provide for absolute and/or relative URI
> | references to that URI.
>
> While this is certainly true, I don't think that this is desirable and
> was afraid that the text was too neutral about that. I don't think
> that we would want to encourage this.
>
> As a matter of fact, I just realized that this is inconsistent with
> the definition given in section 3 which says that secondary parts are
> identified by _a_ URI.
>
> Comment 2:
> ==========
>
> As an example of implementation, the document reads:
>
> |    3. The primary SOAP message part may be exchanged using the HTTP
> |       protocol binding without any further encapsulation
> and the JPEG
> |       image transmitted using a separate HTTP GET request.
>
>
> Basically, this describes a SOAP message which would be carried using
> the HTTP binding, as defined in SOAP Version 1.2 Part 2[2], and which
> would contain references (hyperlinks) outside the envelope.
>
> I was wondering how far the current HTTP binding was from supporting
> the attachment feature, since it seems that getting attachments in
> this case is just a matter for the SOAP processor of doing HTTP GET
> requests to get representations of the resources referenced.
>
> Regards,
>
> Hugo
>
>   1. http://www.w3.org/TR/2002/WD-soap12-af-20020924/
>   2. http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#soapinhttp
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
>

Received on Tuesday, 15 October 2002 19:06:37 UTC