- From: David Orchard <dorchard@bea.com>
- Date: Tue, 4 Feb 2003 14:48:58 -0800
- To: <noah_mendelsohn@us.ibm.com>
- Cc: "'Jean-Jacques Moreau'" <jean-jacques.moreau@crf.canon.fr>, <xml-dist-app@w3.org>
Noah, I'd like to dive into this in a bit more detail. You didn't explain how you thought SOAP messages relate to Representations. Nor did I understand why you didn't agree with my definition that include the phrase "and additional data". I'll try again. Out of the set of data that can be specified in a SOAP message, the only places that it can occur on the wire (or infoset(s)?) are: 1) within a protocol as defined by the protocol (like HTTP methods); 2) within a protocol as defined by SOAP (like SOAP Action); 3) within the envelope. Are you saying that any SOAP-specific binding to a protocol (#1) is defined to be in a SOAP Message yet is not defined by the SOAP media-type (#2 and #3) so therefore a SOAP Message has arbitrarily more information than a Representation? In other words, the scope of a SOAP Message is potentially greater than a representation? So how about this relationship (for your definition of SOAP Message) then, "A SOAP Message is defined as data that is transferred in binding specific manner, a representation that contains a SOAP envelope with representation metadata, and the representation metadata includes a content type of application/soap+xml." I guess where I'm also going is that I'm a little confused about what the soap content-type defines. Does the content type define the SOAP envelope + SOAP specific extensions (aka representation), or does the content type define that PLUS the binding specific data. Is the content type for the representation, or the representation + other stuff. Another way of looking at this, that I think is what you are proposing: SOAP envelope: the envelope construct SOAP Representation: the envelope + soap defined binding extensions SOAP Message: SOAP Representation + soap specific binding to protocols Is this separation that you believe appropriate? BTW, I'm not convinced yet that there is a distinction between a SOAP representation and a SOAP Message in this definition. While I can't see where REST speaks about binding to protocols being in the definition of representations, it also doesn't appear to preclude this. REST talks about representations being the transfer of application state. Perhaps this is an area where some clearer separation or explanation could be done, such as in the web arch document. This seems like a very useful and interesting elaboration. And my take at these two viewpoints: 1) A SOAP infoset is defined as the infoset of a SOAP envelope. SOAP Message contains stuff + SOAP infoset. No such thing as a "SOAP Message infoset". 2) A SOAP infoset is defined as the SOAP Message infoset, which contains a SOAP envelope infoset and additional infoset items. I note that xml vocabularies can define their own extensions to the xml infoset, and many have done so. I don't see anything technical that precludes #2. Maybe there is a worry that the infoset extensions will go to far away from being an xml 1.0 infoset? Cheers, Dave > -----Original Message----- > From: xml-dist-app-request@w3.org > [mailto:xml-dist-app-request@w3.org]On > Behalf Of noah_mendelsohn@us.ibm.com > Sent: Tuesday, February 04, 2003 8:13 AM > To: David Orchard > Cc: 'Jean-Jacques Moreau'; xml-dist-app@w3.org > Subject: RE: What is a SOAP Message > > > > No, I think this still misses the distinction. Specifically, > the data > that moves from point to point in SOAP is, in general, more > than what is > within the scope of the application/soap+xml content type. > It includes a > potentially unbounded set of feature-specific data that is > represented > outside of that media type. One simple example is the so-called Web > Method (GET/PUT/POST), which the HTTP binding represents in > the obvious > http-specific manner, but other bindings (MQSeries, perhaps?) will > represent using some other transport-specific means. > > I find the term "SOAP Message" to be about right for the > collection of > state >that is modelled by SOAP above the binding-specific > layer< and that > moves from one node to another per the SOAP architecture. I > think that is > distinct from the envelope, which is indeed the part of the > (transmission > unit formerly known as message) that is indeed in media type > application/soap+xml. > > Using my terminology, my impression of the options wrt the issue that > Gudge has raised can be explained as: > > * Traditional (Noah): The "message" consists of all the SOAP-modeled > data, including not just the envelope but potentially other > properties > defined by features. One such feature is the attachment > feature, which > defines properties for the parts [1]. The representation of such > properties is at the discretion of the feature and the > protocol binding. > For example, DIME provides a concrete implementation of the > attachment > feature. In general, parts (other than the envelope itself) > are modeled > as being external to the envelope. > > * Infoset-based (Gudge): There are two infosets for each > message related > by a binding-specific transform (not necessarily an XSLT > transform.) By > definition, one of these includes in its XML Infoset some > reprsentation of > every piece of data that would have been in the "message", as I have > defined it above. For example, a part which would otherwise > be binary > might be modeled in characters using a schema type of > hexBinary. This > first infoset provides unity for the processing model, but is > often too > verbose for efficient processing in memory or on the wire. The > responsibility of the binding is to transmit this infoset, > but it is given > hints about problematic content such as that which is of > hexBinary type. > The binding can use such hints to provide optimized > representations on the > wire (carrying the binary as true binary). A transform can > be used to > create a second SOAP envelope which has the binary > information replaced > with pointers to the protocol-specific serialization (this is > the second > infoset listed above). The binding can, if desired, transmit > this second > infoset in the same manner as a traditional SOAP implementation would > transmit the envelope. Presumably, not just the wire > representation but > also the in-memory representations of large binary objects can be > optimized. > > Gudge: is this explanation correct? I still have many > doubts about this > proposal, but I think it's always healthy if one person can explain > another's proposal. Thanks. > > [1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/ > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ > > > > > > > > "David Orchard" <dorchard@bea.com> > 02/04/2003 10:18 AM > > > To: "'Jean-Jacques Moreau'" > <jean-jacques.moreau@crf.canon.fr>, > <noah_mendelsohn@us.ibm.com> > cc: <xml-dist-app@w3.org> > Subject: RE: What is a SOAP Message > > > Maybe a good word for the bag of bits that some are calling a message > would > be better served being called a representation? This would > show a clean > relationship between the web and web services at the > messaging level. The > TAG's work [1] isn't very far along, but it shows a start. > > And if we don't a call a "message" a representation, then we probably > ought > to provide some explanation on how a message and a > representation relate. > It might be as simple as "A SOAP Message is defined as a > representation > that > contains a SOAP envelope, binding specific additional data, > and has the > application/soap+xml content type". > > Cheers, > Dave > > http://www.w3.org/TR/webarch/#representations > > > -----Original Message----- > > From: xml-dist-app-request@w3.org > > [mailto:xml-dist-app-request@w3.org]On > > Behalf Of Jean-Jacques Moreau > > Sent: Tuesday, February 04, 2003 12:30 AM > > To: noah_mendelsohn@us.ibm.com > > Cc: xml-dist-app@w3.org > > Subject: Re: What is a SOAP Message > > > > > > > > I also make the same distinction between messages and envelopes. > > I have seen the confusion made in other groups as well. So, > > > > +1 to your suggested clarification. > > > > Jean-Jacques. > > > > noah_mendelsohn@us.ibm.com wrote: > > > During today's AFTF telcon we got into a discussion as to > > exactly what a > > > SOAP Message is. Gudge pointed out that in several places > > in part 1 it > > > says or strongly implies that a SOAP Message >is< an XML > > Envelope Infoset. > > > I had always assumed we were clear that the "term message" > > refers not just > > > to the envelope, but to a set of information which includes > > at minimum the > > > envelope, but often other information as well (e.g., the > destination > > > address, WebMethod, and Action tend to be sent out of band > > in SOAP http). > > > [...] > > > > > > I think it's useful and appropriate to separate the term > > "message" from > > > "envelope". [...] I think we should consider clarifying our > > terminology. > > > > > >
Received on Tuesday, 4 February 2003 17:51:04 UTC