- From: Tom Jordahl <tomj@macromedia.com>
- Date: Tue, 28 Oct 2003 06:22:18 -0800
- To: "'Umit Yalcinalp'" <umit.yalcinalp@oracle.com>
- Cc: "'WS Description List'" <www-ws-desc@w3.org>
- Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB04C522AF@S1001EXM02.macromedia.com>
Umit wrote:
> As I tried to indicate, we have two issues.
>
> (1) Being able to designate a void return as well as designating an output parameter as the return value (your example).
> (2) Allowing SOAP rpc return value convention to coexist in the RPC style.
OK, so let's talk about your solution to (1) first.
> -- Define an attribute "result" in the rpc namespace. Its value is a QName.
> -- Use the attribute in the output element to designate the return value in the output message (body) itself.
> -- If the attribute does not exist, then there is no return value. You infer that it is void.
> -- It is an error to have this attribute in the output element when the style is not rpc.
This doesn't sound unreasonable to me. I think it might be a little bit strange to introduce this attribute and start defining hard and fast errors that would happen if it shows up without a style attribute, but it certainly seems easy to understand and (better) easy to implement if you are creating a tool which wants to pay attention to the RPC hint. If your tool doesn't, you can ignore it. So I would support this idea.
As for (2), I am indifferent as to whether we have support for this in WSDL or not. I would be fine if we said we didn't, since we are not supporting the SOAP data model either. Do we think users of SOAP RPC will be doing WSDL? If Schema can't represent the data model, that would seem like a big problem and I would probably just skip WSDL altogether if I were using it. But I am just guessing.
--
Tom Jordahl
Macromedia Server Development
-----Original Message-----
From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
Sent: Monday, October 27, 2003 9:44 PM
To: Tom Jordahl
Cc: 'Jacek Kopecky'; 'WS Description List'
Subject: Re: RPC Style Issues (3)
Tom Jordahl wrote:
Jacek wrote:
On the issue that you actually have my opinion is that it doesn't matter
if the two functions void f([out]int x) and int f()
are equivalent to WSDL. While it means that in some cases the round-trip
from a programming language interface to WSDL and back may break, aiming
for the 90/10 (or better) case means we don't want to introduce the
SOAP-like indirect designation of the return element. Anyway, IMO the
round-trip issue is out of scope for WSDL, even though the RPC rules
might want to point this issue out.
I think this is the key on this issue. Do we care if an RPC style WSDL can come out with two different signature?
void f([out] int x)
int f()
Tom,
This is an excellent example. With the current rules, only the second signature is implied. We need a mechanism to designate both. I disagree with Jacek's point.
I would prefer if we could avoid this by giving some clear direction in the specification, but I don't think we should try to move toward a SOAP RPC-like indirect return element thingy.
As I tried to indicate, we have two issues.
(1) Being able to designate a void return as well as designating an output parameter as the return value (your example).
(2) Allowing SOAP rpc return value convention to coexist in the RPC style.
The WG can make an explicit decision not to allow (2). Lets not mix the two.
I would like to solve problem (1). We should decide whether (2) is acceptable or not, but (1) must be solved and yield two different signatures. This is NOT a 80/20 problem. From our perspective, they both exist and *are* different.
I propose another approach to solve (1) which was mentioned but not clearly spelled out in my message starting this thread.
-- Define an attribute "result" in the rpc namespace. Its value is a QName.
-- Use the attribute in the output element to designate the return value in the output message (body) itself.
<interface name="whatever" ...>
<operation name="foo" pattern="..." style="http://www.w3.org/@@@@/@@/wsdl/style/rpc <http://www.w3.org/@@@@/@@/wsdl/style/rpc> " >
<input.../>
<output messageReference="..."
body="..."
rpc:result="tns:myValue"/>
</interface>
-- If the attribute does not exist, then there is no return value. You infer that it is void.
-- It is an error to have this attribute in the output element when the style is not rpc.
Basically, it is functionally equivalent to defining the result without using the SOAP convention inside the message. Further, the message is not changed. Instead it is defined in WSDL, but allows one to infer two distinct signatures as needed.
--umit
--
Tom Jordahl
Macromedia Server Development
-----Original Message-----
From: Jacek Kopecky [mailto:jacek.kopecky@systinet.com <mailto:jacek.kopecky@systinet.com> ]
Sent: Friday, October 24, 2003 9:22 AM
To: Umit Yalcinalp
Cc: WS Description List
Subject: Re: RPC Style Issues (3)
Umit, others, please see inside.
Jacek Kopecky
Systinet Corporation
http://www.systinet.com/ <http://www.systinet.com/>
On Thu, 2003-10-09 at 06:09, Umit Yalcinalp wrote:
(a) The methodology does not follow the SOAP 1.2 rules for rpc [1].
Hence, the SOAP 1.2 rules are not allowed given the current proposal. We
think that this is a major issue. Our RPC rules should enable the use of
SOAP 1.2 RPC representation, or at least not disallow the use of SOAP
1.2 RPC representation. More on this below.
IMHO if we specify RPC rules that are different from SOAP 1.2 rules we
aren't disallowing the SOAP 1.2 rules, just not supporting them with
this operation style. I agree that this should be stated explicitly to
avoid confusion.
One of our reasons for not supporting SOAP 1.2 RPC could be that we
don't even support SOAP 1.2 Data Model, and SOAP 1.2 RPC is built on top
of that. Both supports could be added later, but as they cannot use XML
Schema, we must provide an XML-Schema-friendly RPC, too, otherwise our
users would probably complain.
(b) It is impossible to have a "void" return type when there are only
output parameters. This is due to the fact that the current rule is too
restrictive. For example, for a function that has a single output
parameter that does not return a value the rule will label the output
parameter as a result. This behaviour is simply incorrect for our
purposes. We thought of using other rules, but found out that *without*
designating a result value externally to the output values being
returned, it is impossible to do this.
At first (at the conf-call) I mistook your issue for not being able to
specify a null return value (with non-void return type) reliably. I
apologize for that.
On the issue that you actually have my opinion is that it doesn't matter
if the two functions void f([out]int x) and int f()
are equivalent to WSDL. While it means that in some cases the round-trip
from a programming language interface to WSDL and back may break, aiming
for the 90/10 (or better) case means we don't want to introduce the
SOAP-like indirect designation of the return element. Anyway, IMO the
round-trip issue is out of scope for WSDL, even though the RPC rules
might want to point this issue out.
Maybe revisiting the SOAP 1.2 rules may be fruitful to solve these two
problems. Lets give an example for how SOAP 1.2 rules would designate a
return value:
The return value in [1] is indicated by the value of the EII
{http://www.w3.org/2003/05/soap-rpc <http://www.w3.org/2003/05/soap-rpc> }result. For example, an response for
a Java method, float getStockQuote (String symbol) may look like this:
<SOAP:Envelope...> <SOAP:Envelope ...>
<SOAP:Body...> <SOAP:Body ...>
<myns:getStockQuote ...>
<rpc:result rpc:http://www.w3.org/2003/05/soap-rpc <http://www.w3.org/2003/05/soap-rpc> >
return-value
</rpc:result>
<return-value>10e0</return-value>
</myns:getStockQuote>
</SOAP:Body <SOAP:Body> >
</SOAP:envelope <SOAP:envelope> >
Here the element rpc:result is NOT part of the signature, but allows one
to identify the return value. The absence of rpc:result implies that the
return type of the method was 'void'.
This allows the SOAP message to "dynamically" identify the return value.
In the context of WSDL, what the RPC rules are trying to do is to
identify the return value "statically". Given that most language
bindings (at least the interfaces) will rely on "static" WSDL
information to generate the signature, the return value will be
determined from the WSDL.
However today with the adopted changes by removing message/parts, the
message content is completely defined by the definition of input and/or
output elements directly in the schema. Therefore the scheme provided by
SOAP 1.2 requires us to define the result element in the schema.
So the question that has to be answered is how to define rules that do
not contract SOAP 1.2 without adopting SOAP 1.2 RPC representation. The
problematic part is the "rpc:result" element which appear to be very
SOAP specific. The only way to solve the problem is to make an exception
for the rpc:result element. Since this is in SOAP 1.2 NS, this should
not really be a problem for non-SOAP mappings at the binding level.
I don't think we want to require all non-SOAP bindings to have an
exceptional case handling a SOAP 1.2 artifact.
In order to do this, we need to modify the existing rules to say:
- Output elements also contain only local element children with the
exception of {http://www.w3.org/2003/05/soap-rpc <http://www.w3.org/2003/05/soap-rpc> }result.
- The child elements of input and output represent input and output
parameters of the operation ("<part>" in WSDL 1.1), except for the child
element {http://www.w3.org/2003/05/soap-rpc <http://www.w3.org/2003/05/soap-rpc> }result.
...
Alternately, we can have a blanket exception for the element
{http://www.w3.org/2003/05/soap-rpc <http://www.w3.org/2003/05/soap-rpc> }result.
What this means is that the a SOAP message cannot dynamically designate
the return value, but since the inputs & outputs of a function are
statically defined in WSDL and the designation of a result with a
special element must be specified in the schema.
How do we indicate that, for example, the 'return-value' out-parameter
in my operation is the return value? I don't think XML Schema allows us
to say that the soaprpc:result element will have the fixed value of
myns:return-value. IOW we would force the dynamic evaluation of the
return value accessor onto otherwise static operations. Tools generating
interfaces from WSDL wouldn't be able to guess which of the out
parameters is the return value.
If we don't do this, we need to say explicitly that SOAP 1.2 RPC
representation will not be supported by WSDL 2.0. Therefore, we should
revisit this issue.
Again, that's maybe until we support SOAP 1.2 Data Model (if ever).
Alternative way to do this is to designate an attribute defined in WSDL
namespace that can be optional and be used in an operation component to
name the element that would designate the return value. This attribute
is only allowed to be used when rpc style is indicated. The alternate
method declares the return value statically, but suffers the same
problem of not allowing SOAP 1.2 rpc rules to be followed.
I don't think we can say the attribute may only be used with the RPC
style - it would be hard to enforce (not impossible) in implementations.
It seems to me that making an exception to allow using the soap
namespace designated element without requiring that a SOAP binding to be
be used may be killing two birds with one stone.
An ugly stone, that is. 8-)
[1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc <http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc>
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html <http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html>
--umit
--
Umit Yalcinalp
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154
Email: umit.yalcinalp@oracle.com <mailto:umit.yalcinalp@oracle.com>
--
Umit Yalcinalp
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154
Email: umit.yalcinalp@oracle.com <mailto:umit.yalcinalp@oracle.com>
Received on Tuesday, 28 October 2003 09:22:35 UTC