Parameter order resurrected

Hello,

On Thursday's call I mentioned the possibility of resurrecting our
good old friend @parameterOrder (all fixed up and speced out, of course)
and near the end of the call Jonathan asked for someone to write up what
such an attribute would look like.

So here's a possible definition for it. Please note that I'm not
going as far as making this a proposal to the WG yet, it's simply
intended to be a visual aid for Monday's discussion.

The starting observation is that the hints on the function signature
implied by an rpc-style operation (colloquially referred to as "the
second bucket") in effect amount to a description of an algorithm that
a tool can use to reconstitute the function signature implied by
the WSDL author. It's natural then to wonder why wouldn't the
aforementioned WSDL author just state what the function signature is,
instead of using such a circuitous mechanism.

Here's a definition of an rpc:signature extension attribute:

<xs:schema targetNamespace="http://www.w3.org/@@@@/@@/wsdl/style/rpc"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:tns="http://www.w3.org/@@@@/@@/wsdl/style/rpc">

   <xs:attribute name="signature" type="signatureElementList"/>

   <xs:simpleType name="signatureElementList">
     <xs:list itemType="signatureElement"/>
   </xs:simpleType>

   <xs:simpleType name="signatureElement">
     <xs:union memberTypes="tns:specialElement xsd:QName"/>
   </xs:simpleType>

   <xs:simpleType name="specialElement">
     <xs:restriction base="xs:token">
       <xs:enumeration value="##in"/>
       <xs:enumeration value="##out"/>
       <xs:enumeration value="##inout"/>
       <xs:enumeration value="##return"/>
     </xs:restriction>
   </xs:simpleType>

</xs:schema>

In what follows I give an example of its usage, with the intent
of doing "specification by example" (for now).

Assume that the input and output message for an operation Op are
defined as follows:

<xs:element name="Op">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="a" type="xsd:string"/>
       <xs:element name="b" type="xsd:int"/>
     </xs:sequence>
   </xs:complexType>
</xs:element>

<xs:element name="OpResponse">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="c" type="xsd:float"/>
       <xs:element name="b" type="xsd:int"/>
     </xs:sequence>
   </xs:complexType>
</xs:element>

Here's the boilerplate operation definition for Op:

<wsdl:operation
	name="Op"
	pattern="{{in-out}}"
	style="{{rpc-style}}"
	rpc:signature="{{signature}}">
   <wsdl:input messageReference="in" body="tns:Op"/>
   <wsdl:input messageReference="out" body="tns:OpResponse"/>
</wsdl:operation>

And here are different values for {{signature}} corresponding
to different function signatures (in simil-IDL):

void Op([in] string a, [inout] int b, [out] float c)
	==>  "a ##in b ##inout c ##out"

void Op([out] float c, [in] string a, [inout] int b)
	==>  "c ##out a ##in b ##inout"

float Op([inout] int b, [in] string a)
	==>  "b ##inout a ##in c ##return"

In other words, the rpc:signature attributes lists the parameters
in order, each tagged with its role (in/out/inout/return).

The spec for the rpc:signature extension would state all the usual
requirements (all parameters MUST appear, all in parameters MUST
be present in the input message and MUST NOT be in the output, etc.).

If we wanted to, we could even allow multiple, ordered return values,
and make Common Lisp and Python users happy!  ;-)

Being an extension, processors that don't care about it can disregard
the signature, nothing new here. Processors that understand the
signature will validate it using the rules, but don't need to infer
anything, because the signature is spelled out in full.

Regards,
Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Friday, 31 October 2003 19:26:05 UTC