RE: {rpc signature} ambiguity causes 2 interchange failures for Woden

Thanks for the report – I’ll upload the new rollup shortly.

 

First, I think this is just a bug in wsdl-xslt.  The spec clearly states
that the property MUST be present if the style is rpc, and wsdl-xslt clearly
isn’t doing that.  The rpc signature description specifically notes that the
property might be empty.  I’ll fix.

 

After that, I’m not sure much remains to be clarified in the spec, but I’ve
opened http://www.w3.org/Bugs/Public/show_bug.cgi?id=4563 to track it in
case there is.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of John Kaputin (gmail)
Sent: Monday, May 14, 2007 7:52 AM
To: WS-Description WG
Cc: woden-dev@ws.apache.org
Subject: {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
Baseline.

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†." 

regards,
John Kaputin