- From: Hugo Haas <hugo@w3.org>
- Date: Fri, 18 Oct 2002 17:09:47 +0200
- To: xmlp-comments@w3.org
- Cc: www-ws-arch@w3.org
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:53 UTC