Re: SOAP 1.2 Attachment Feature review

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

Comment 2
---------

The SOAP encoding allows references by IDREFs inside the SOAP
envelope. A natural and common way to reference something on the Web
is to use a reference to a resource using an http: URI. The
Attachment Feature document suggests that such references are to be
handled by the Attachment Feature (example 3 in section 6[3]).

It is unclear, with the current SOAP Version 1.2 specification, how
such URIs would be dereferenced, i.e. as part of the HTTP binding,   
by the SOAP processor, etc. Some clarity about this example is
desired.

Also, in such a case where the secondary parts do not travel along
with thi message, the term "attachment" is awkward to talk about those
resources that need to be dereferenced.

Comment 3
---------

I am concerned about the interaction of URI addressing schemes to
secondary parts and the SOAP execution model which permits various
SOAP headers to be inserted and deleted by intermediaries under
appropriate conditions (roles must match, software modules must exist,
etc.).  Are there similarly conditions under which intermediaries may
insert and delete secondary parts?  For example, are they allowed to
create "dangling URIs"?

Secondly, is it clear which URI schemes are impervious to insertion,
deletion, and modification of secondary parts?  For example, might
there be a uniqueness problem with IDREFs?

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 16 October 2002 12:45:21 UTC