- From: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
- Date: Fri, 15 Feb 2002 18:45:36 -0500
- To: <tjewald@develop.com>
- Cc: "xml-dist-app" <xml-dist-app@w3.org>
>> 2) No support for graphs
Right. All I'm saying is that we shouldn't fall into the trap of fudging
our model of the endpoint just because we know what we want the wire format
to be.
* I think that to properly model this you need to say:
"We model a procedure as taking (named? ordered?) arguments each of which
is typed as an XML Element information item. Mappings to the data
structures of particular programming systems at the endpoints is beyond the
scope of this specification (so, we don't really give a standard
representation for)
x =someMethod (int i)
Conversely, we could introduce a more explicit model of what method calls
look like, and explain how the serialized XML is to relate to the model.
* We must also be clear on whether id like references mean anything for
RPC, and whether they can connect otherwise unrelated arguments. Saying
there's not graph suggests that such href/id constructions SOULD NOT occur
in the XML. That's different than document literal. Whatever we mean, we
should call it out. Such items (may? must not?) within their content
contain references to elements not within the tree to represented by the
argument itself. (If allowed...) Such references are represented by (an
attribute named href which must have as its value the contents of an
attribute named id on some other element in the soap element; the contents
of such IDs must be unique.)
Overall: I have always had doubts about the wisdom of the graph model in
SOAP, but it's also very late in the process to be questioning it. Count
me as more or less neutral on the technial merits, but very concerned that
whatever we adopt be modeled and explained very carefully and precisely.
------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
IBM Corporation Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
"Tim Ewald"
<tjewald@develop To: "'XMLDISTAPP'" <xml-dist-app@w3.org>
.com> cc:
Sent by: Subject: RE: Issue with soap-rpc:result
xml-dist-app-req
uest@w3.org
02/14/02 03:18
PM
Please respond
to tjewald
> 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 19:40:59 UTC