{rpc signature} ambiguity causes 2 interchange failures for Woden

I have uploaded new Woden test results after correcting the style defaulting
problem reported by Jacek, but Woden is still failing 2 test cases; RPC-1G
and RPC-2G. I think there's an ambiguity in the spec that has led to
different implementation assumptions between Woden and the Interchange

Part 2 section "4.1.1 wrpc:signature Extension" seems to be saying:

1) that wrpc:signature MAY be used if {style} is RPC, and
2) that if wrpc:signature is used it will contribute the {rpc signature}
property, and
3) that the {rpc signature} property MUST be present if {style} is RPC.

So it infers that {rpc signature} could still be present even if
wrpc:signature is omitted from the WSDL (that is, if wrpc:signature is not
used when {style} is RPC). Is this a valid state?

Test cases RPC-1G and RPC-2G omit the wrpc:signature extension attribute
from the WSDL but produce a component model where the {style} is RPC. So
assuming {rpc signature) MUST be present because the {style} is RPC, what
should it's value be for these 2 test cases?

Woden exposes the {rpc signature} on its API if the {style} is RPC, but for
these 2 test cases the API returns null for the {rpc signature} property.
This disagrees with the Interchange baseline, which assumes that the {rpc
signature} property is not present (even though the {style} is RPC).

If in fact {rpc signature} can ONLY be contributed by wrpc:signature (which
seems sensible to me), then maybe the assertion in step 3) should say:

"{rpc signature} OPTIONAL, but MUST be present when the style is RPC and
wrpc:signature is present†."

or, if we can be this strict about it:

"{rpc signature} OPTIONAL, but MUST be present if and only if the style is
RPC and wrpc:signature is present†."

John Kaputin

Received on Monday, 14 May 2007 15:02:01 UTC