"Sam Ruby" <[EMAIL PROTECTED]> writes: > Russell Butek wrote: > > > > The WSDL is illegal. Two problems with parameterOrder. First, as you > > said, it should list the parts. Secondly, as Sanjiva tells me, if > > parameterOrder is used at all, it is illegal to NOT list all input > > parameters. Yes, this is a doc/lit WSDL, but that really just means that > > it sends a doc/lit message. We're generating RPC-style bindings whether or > > not it's rpc/encoded, so we can't ignore the parameterOrder "hint". > > Illegal is a strong word - can you point to a reference? I can't find this > restriction in the WSDL documentation, and furthermore it does seem to go > out of its way to refer to this as a hint.
The WSDL is flat out illegal. The things listed in parameterOrder are supposed to be part names. Do you see parts named "customerID" and "amount" anywhere? Those are elements within the message part "chargeRequest"!! Now looks like this is a WSDL designed for the .Net magical "unwrap doc/lit to do what I meant" crap. That is all out nonsense; that is absolutely non-compliant with the WSDL 1.1 spec. I have no doubt my MSFT co-authors of WSDL 1.1 would totally agree that that WSDL is wrong. The error message from WSDL2Java could be improved to say "Unable to find part 'customerID'" or something like that. Other than that I agree its behavior is correct. > >From their perspective, they *ARE* listing all of the parameters - > WSDL2Java simply differs in its interpretation of what the parameters > are... There's only one interpretation allowed by WSDL 1.1 - they are parts of a message. Here's what the spec says about parameter order: =========== 2.4.6 Parameter Order within an Operation Operations do not specify whether they are to be used with RPC-like bindings or not. However, when using an operation with an RPC-binding, it is useful to be able to capture the original RPC function signature. For this reason, a request-response or solicit-response operation MAY specify a list of parameter names via the parameterOrder attribute (of type nmtokens). The value of the attribute is a list of message part names separated by a single space. The value of the parameterOrder attribute MUST follow the following rules: a.. The part name order reflects the order of the parameters in the RPC signature b.. The return value part is not present in the list c.. If a part name appears in both the input and output message, it is an in/out parameter d.. If a part name appears in only the input message, it is an in parameter e.. If a part name appears in only the output message, it is an out parameter Note that this information serves as a "hint" and may safely be ignored by those not concerned with RPC signatures. Also, it is not required to be present, even if the operation is to be used with an RPC-like binding. =========== Note the sentence "The value of the attribute is a list of message part names separated by a single space." Its not in this case. The spec does not leave wiggle room by design. How can you possibly argue that this WSDL is legal?!! > Net: the WSDL doc doesn't seem to preclude this. Other toolkits don't seem > to mind. Nothing against Sanjiva, but I would like something a little more > authoritative than "Sanjiva tells me". ;-) When the WSDL spec isn't precise on something (as it is in many cases), I believe that the "intent" of the spec authors should have some authority, don't you? In any case, everything is 100% clear in this case. The spec says that the things in parameterOrder have to be part names. In this case they are not. Done deal. Sanjiva.
