Proposal to address LC75g

At the last f2f I got an action item to formulate a proposal to handle
LC75g: "RPC should allow element wildcards".

==== PROPOSAL ====

In section 2.4.2, amend the second bullet point, currently

[[
The sequence MUST only contain elements. It MUST NOT contain other 
structures such as xs:choice.
]]

to read

[[
The input sequence MUST only contain elements and element wildcards.  It
MUST NOT contain other structures such as xs:choice. The input sequence
MUST NOT contain more than one element wildcard. The element wildcard,
if present, MUST appear after any elements.

The output sequence MUST only contain elements. It MUST NOT contain 
other structures such as xs:choice.
]]

In section 2.4.2.1, replace

[[
3. Then the formal signature of the function is

     f([d0] a0, [d1] a1, ...) => (r0, r1, ...)
]]

with

[[
Then, if the input sequence ends with an element wildcard, the formal 
signature of the function is

     f([d0] a0, [d1] a1, ..., rest) => (r0, r1, ...)

where "rest" is a formal parameter representing the elements in the
input message matched by the element wildcard.

Otherwise, the formal signature of the function is

     f([d0] a0, [d1] a1, ...) => (r0, r1, ...)
]]

==== RATIONALE ====

Allowing element wildcards in the input/output messages is good for
versioning. A service author can add new parameters to an existing
RPC-style operation without impacting existing clients.

A number of programming languages provide first-class support for
passing a variable number of arguments to a method/procedure/function,
so the proposal allows element wildcards in input messages.

Programming language bindings will map the "rest" argument used in the
formal signature above to the appropriate language-specific construct.

Some examples:

1. C/C++

     printf(const char *format, ...)

2. Java

     MessageFormat.format(String pattern, Object... arguments)

3. C#

     void test(int a, params object[] b)

4. Python

     def foo(a, *args, **kwds)

5. Common Lisp

     (lambda (a b &rest c) ( ... ))

Since substantially fewer languages provide similar first-class support
for a variable number of [out] or [return] arguments (only Common Lisp
comes to mind) the proposal restricts the use of wildcards to input
messages only.

There being more programming languages than stars in the sky, don't take
any of the statements above as exhaustive (says he, ducking for cover as
he awaits the inevitable language war that will follow).

Roberto

Received on Thursday, 10 March 2005 19:04:57 UTC