- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Tue, 28 Oct 2003 14:55:32 -0800
- To: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Cc: Tom Jordahl <tomj@macromedia.com>, WS Description List <www-ws-desc@w3.org>
- Message-ID: <3F9EF3E4.7060604@oracle.com>
Jeffrey Schlimmer wrote:
> Would it make sense to define the style attribute in the RPC namespace
> too?
>
>
>
> --Jeff
>
I don't think so. It will be too restrictive. It depends, of course,
whether you don't want to see other styles in the operation, such as
operations designating attributes or some other mapping thing that we
have not envisioned yet.
--umit
>
>
> ------------------------------------------------------------------------
>
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On Behalf Of Tom Jordahl
> Sent: Tuesday, October 28, 2003 6:22 AM
> To: 'Umit Yalcinalp'
> Cc: 'WS Description List'
> Subject: RE: RPC Style Issues (3)
>
>
>
> 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" >
> <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]
>
>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/
>
>
>
>
>
>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}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>
>>
>> return-value
>>
>> </rpc:result>
>>
>> <return-value>10e0</return-value>
>>
>> </myns:getStockQuote>
>>
>> </SOAP:Body>
>>
>></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}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}result.
>>
>>
>>
>>...
>>
>>
>>
>>Alternately, we can have a blanket exception for the element
>>
>>{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
>>
>>[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html <http://dev.w3.org/cvsweb/%7Echeckout%7E/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>
>
>
>
--
Umit Yalcinalp
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154
Email: umit.yalcinalp@oracle.com
Received on Tuesday, 28 October 2003 17:56:18 UTC