SOAP 1.2 Attachment Feature review by the Web Services Architecture Working Group

On behalf of the Web Services Architecture Working Group, please find
below the comments from the Web Services Architecture Working Group
concerning:

	SOAP 1.2 Attachment Feature
	W3C Working Draft 24 September 2002
	http://www.w3.org/TR/2002/WD-soap12-af-20020924/

Apologies for being a few days late.

Regards,

Hugo

  -------------------------------------------------------------------

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

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://example.com/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."

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

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 this message, the term "attachment" is awkward to talk about those
resources that need to be dereferenced.

Comment 3
---------

We are 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?

Comment 4
---------

The Web Services Architecture Working Group encourages the XML
Protocol Working Group to produce a concrete packaging (attachment)
specification to validate the SOAP/1.2 Attachment Feature
specification. A normative standard for a concrete specification is
also important for reference from other standards and specifications
and is considered a high priority by the WSAWG.

The XML Protocol Working Group  may be the most appropriate venue for
this work; if not, the Web Services Architecture Working Group will
probably recommend that a new Working Group be chartered to do this in
the near future because the lack of a concrete specification that can
be the basis for interoperable SOAP attachments implementations is a
hole in the Web services architecture that needs to be addressed as
soon as possible.

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

Received on Friday, 18 October 2002 11:09:54 UTC