RE: Issue with soap-rpc:result

 Tim, 
 I'm very nervous everytime somebody uses the term "document" 
message, "literal" message, "encoded" message and variations.
 A message in WSDL is never specifically one of these, but I 
don't think it's WSDL messages that are talked about.
 A SOAP message has a Body, which has some contents. The contents
may follow the RPC convention, in which case their meaning is set
by the convention. They may be encoded using some encoding rules, 
in which case their value is specified by said rules.
 The document or rpc style in WSDL does not at all matter for the 
actual SOAP messages for their interpretation is left on the 
application. Of course it is simpler to model messages that 
should follow the RPC convention using rpc style, but hey, 
document style can model any messages describable by a schema, 
right? 8-)
 The encoded or literal use of schemata in WSDL again does not 
matter for the actual SOAP messages, it just constrains the 
sender on its interpretation of the schemata.
 Therefore, I postulate that there is no such thing as a 
"document/literal" message.

 And I still maintain my original position that you CAN define 
messages using XML Schema. Yes, you use WSDL's document style and 
literal use to do that. It is no heresy not to use the RPC 
convention because the view of what is or is not RPC is very much 
a matter of taste. It is further no heresy not to use the SOAP 
Encoding, for some applications already have their formats in XML 
and why change that, other applications' data may be incompatible 
with the Encoding's assumptions and should not be forced.

 If you choose to use the RPC convention and the SOAP Encoding, 
well, you do agree with some rules and why do you still want to 
use XML Schema to describe the messages strictly? For the RPC 
structures, XML Schema is unnecessary because WSDL's "rpc" style 
takes care of these structures. For data structures, XML Schema 
schemata may either be followed (in which case they may or may 
not permit references, for example), or may be interpreted 
according to the "encoded" use, in which case they are just an 
approximation of the real schemata.

 Best regards (and no offense meant 8-) ),

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Thu, 14 Feb 2002, Tim Ewald wrote:

 > > Maybe I've misunderstood.  I should confess to not having actually 
 > > programmed with any of the systems such as .Net that provide 
 > > automatic 
 > > document style mappings.  I strongly suspect that they deal best with 
 > > stylized uses of XML, in which case they are in some sense 
 > > encoded.  I 
 > > could be wrong about that.  If so, please let me know what 
 > > I'm missing.
 > 
 > ASP.NET WebMethods support an RPC programming model on top of
 > "document/literal" messages by default (you can enable SOAP encoding if
 > you want to). There are two major limitations:
 > 
 > 1) No support for derivation by restriction
 > 2) No support for graphs
 > 
 > The first problem is simply an implementation issue that can be fixed
 > later, it just takes time. The second problem exists by design: they
 > want all messages to be literal instances of a generated schema. The
 > practical side effect is that graphs will be converted to trees. For
 > instance, if you make a call like this:
 > 
 > Point p = new Point(10, 20);
 > float f = proxy.Distance(p, p);
 > 
 > the resulting SOAP message will look like this:
 > 
 > <soap:Body>
 >   <ns:Distance>
 >     <p1><x>10</x><y>20</y></p1>
 >     <p2><x>10</x><y>20</y></p2>
 >   </ns:Distance>
 > </soap:Body>
 > 
 > In this case, the ASP.NET plumbing assumes the first child of body
 > identifies an operation and each of its children is mapped to a
 > parameter. The implementation of the remote endpoint will deserialize
 > two Point objects with the same x and y values. As a result, the
 > implementation of Distance cannot compare pointer values, as in:
 > 
 > float Distance(Point p1, Point p2)
 > {
 >   if (p1 == p2) return 0.0; // won't work
 >   if (p1.x == p2.x && p1.y == p2.y) return 0.0; // will work
 >   ... // TBD by Pythagoras
 > }
 > 
 > We can debate whether or not this is sufficient for an RPC
 > infrastructure.
 > 
 > The .NET implementation is actually a little bit more complicated than
 > this because it also supports mapping the callstack above to a SOAP
 > message that looks like this:
 > 
 > <soap:Body>
 >   <ns:p1><x>10</x><y>20</y></ns:p1>
 >   <ns:p2><x>10</x><y>20</y></ns:p2>
 > </soap:Body>
 > 
 > In this case, there is not identifier for the operation and each child
 > of the body is treated as a parameter. In this case, the operation is
 > selected either by the SOAPAction or by the contents of the body (as
 > long as every operation has a single, uniquely named parameter). I
 > believe this is primarily in response to WSDL, they (and other SOAP
 > toolkit vendors) have created mappings for all of the different ways you
 > can describe operations in WSDL, whether they make a great deal of sense
 > or not.
 > 
 > Anyway, I still maintain my original position. I want a world where I
 > can define message formats using XSD. I want that because I've got a
 > whole bunch of XSD-aware tools, with more coming. If there is a going to
 > be a SOAP data model, an encoding and an RPC model, I would like it to
 > be simple enough that I can write an XSD for the encoded message format.
 > We've talked already about the desire to write contracts at the
 > graph-level without specifying an encoding, but I think this is a
 > mistake. I believe there are ultimately going to be a lot more systems
 > that care about tight integration with XSD than with the ability to send
 > a graph via n different encodings.
 > 
 > Tim-
 > 
 >

Received on Friday, 15 February 2002 08:47:18 UTC