W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

Re: SOAP 1.2 Attachment Feature review

From: <jones@research.att.com>
Date: Fri, 11 Oct 2002 09:22:44 -0400 (EDT)
Message-Id: <200210111322.JAA05287@bual.research.att.com>
To: dorchard@bea.com, hugo@w3.org, jones@research.att.com, www-ws-arch@w3.org

My comments on URI's are at the left margin below.

	From hugo@w3.org Thu Oct 10 20:29 EDT 2002
	X-UIDL: =\Y!!PJ4"!:2l!!7P/"!
	Delivered-To: jones@research.att.com
	X-Authentication-Warning: mail-pink.research.att.com: postfixfilter set sender to hugo@w3.org using -f
	Date: Fri, 11 Oct 2002 10:29:06 +1000
	From: Hugo Haas <hugo@w3.org>
	To: www-ws-arch@w3.org, David Orchard <dorchard@bea.com>,
	        Mark Jones <jones@research.att.com>
	Subject: Re: SOAP 1.2 Attachment Feature review
	Mail-Followup-To: www-ws-arch@w3.org,
		David Orchard <dorchard@bea.com>, Mark Jones <jones@research.att.com>
	Mime-Version: 1.0
	Content-Disposition: inline
	User-Agent: Mutt/1.4i
	X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20

	Following today's teleconference, I am kicking off the finalization of
	the text we will send to the XML Protocol Working Group.

	* Hugo Haas <hugo@w3.org> [2002-10-02 17:27+0900]
	> 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.

	It seems that other people expressed comments about use of URIs in
	this specification.

	Dave and Mark, could you please send a written version of yours?

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?

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

	There was some confusion about the HTTP binding, HTTP hyperlinks in a
	SOAP message and the Attachment Feature.

	I am proposing to reword this part as follows:

	  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

	Does that represent the opinions expressed on the call?



	  3. http://www.w3.org/TR/2002/WD-soap12-af-20020924/#implementation
	Hugo Haas - W3C
	mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Friday, 11 October 2002 09:23:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:41 UTC