I believe the following to be a correct reading of the spec:
1. The portType/operation and binding/operation elements each have name
attributes which are required and must match.
2. The portType/operation/{input, output} elements have message
attributes which are required and must match the message element names.
3. The portType/operation/{input, output} elements have name attributes
which are optional according to the grammar but default to values given by
an algorithm in section 2.4.5 if not provided.
4. The binding/operation/{input, output} elements do *not* have name
attributes, according to the schema in the appendix, but are allowed to have
names according to section 2.5. However, the improved schema for wsdl
currrently at the xmlsoap.org site *does* have optional name attributes on
these messages.
5. The spec does not explicitly say in section 2.5 that
binding/operation/input@name must match portType/operation/input@name (and
similarly for output) if an ambiguity needs to be resolved where there are
two or more possible operations on the same portType with the same name, but
clearly, this is the only possible way to do it with the given information.
Using that improved schema, the change A. Elder suggested to the XEMBL.wsdl
mentioned in the bug report (providing name attributes to the
binding/operation/{input,output} elements, preserves its validity. Against
the schema in the appendix to the spec, I think the change would be invalid.
Forcing rewrites of wsdl descriptors already in use for a considerable time
seems like a bad idea, given that in this case, there are no ambiguities.
The correct operation can be determined from the operation name alone, so
failing to determine is probably not acceptable, and newly requiring values
of attributes which are supposed to be optional except when needed to
resolve ambiguity should probably not be acceptable either.
The question raised by O. Burroughs, as to whether it's legal to specify the
portType/operation/input@name but not the binding/operation/input@name seems
to me to have a definite answer. The latter attributes are optional, but
the former attributes are optional but have a default value according to
2.4.5, hence always exist implicitly at least. Thus, if the latter
attributes must be allowed to be unspecified as long as there is no
amibiguity.
Thus, the getBindingOperation code must be prepared to find an operation
without the help of binding/operation/input and output message names, unless
an ambiguity has to be resolved.
Jeff
----- Original Message -----
From: "Owen D Burroughs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 27, 2002 4:36 AM
Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation
confusion about message names
>
> Ant,
>
> You misquoted me slightly :-)
>
> Here's a slightly more detailed version of my proposed "wsif-only" fix:
>
> Try to find the bindingOperation using the input/output names given. Then
> if no match is found, try using null for the input/output names. If a
match
> is then found we know that only one operation exists in the binding with
> the same name as the operation we're looking for (for more details see the
> com.ibm.wsdl.BindingImpl.getBindingOperation method in wsdl4j). Now check
> the input/output names of the "matched" bindingOperation object. If they
> are null then we accept it as a match. If they are not null then we
> consider it to be a different operation.
>
> One downside to this is that you inspect/iterate over the binding
> operations twice. It's also still up for debate as to whether specifying
> input/output names in a port type operation and not specifying them in the
> corresponding binding operation is valid. The spec suggests it isn't for
> overloaded operations, which makes sense, but seems to allow any
> combination of port type/binding, input/output names for non-overloaded
> operations.
>
> Owen
>
> Owen Burroughs
> [EMAIL PROTECTED]
>
>
>
> |---------+---------------------------->
> | | Anthony |
> | | Elder/UK/IBM@IBMG|
> | | B |
> | | |
> | | 27/09/2002 11:58 |
> | | Please respond to|
> | | axis-dev |
> | | |
> |---------+---------------------------->
>
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
> |
|
> | To: [EMAIL PROTECTED]
|
> | cc: "Jeff Greif" <[EMAIL PROTECTED]>
|
> | Subject: [wsif] Bug 13038 - WSIF's dynamic port/operation
creation confusion about message names
|
> |
|
> |
|
>
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
>
>
>
> There's a bugzilla bug raised for wsif,
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13038, to do with wsif
> not correctly finding an operation.
>
> The problem is because the wsdl, http://www.ebi.ac.uk/xembl/XEMBL.wsdl,
> specifies an input name on the operation in the portType, but does not
> specify a name on the input in the binding. This causes the wsdl4j method
> getBindingOperation in com.ibm.wsdl.BindingImpl to return null when wsif
> calls it with the operation, input, and output names from the portType.
>
> Reading the wsdl spec it not clear to me if it is valid wsdl to leave out
> the names on the binding when they're specified in the portType.
>
> If it is valid is this a wsdl4j bug or should wsif work around it?
>
> We could fix it in wsif by doing something like (thanks Owen) trying to
> find the bindingOperation using the input/output names given, then if no
> match is found try using null for the input/output names, and then if
still
> no match is then found check to see if the binding input/output names for
> the matched operation are null. If they are then use that
bindingOperation.
> If not then return null since it is not a "match".
>
> What does anyone think?
>
> ...ant
>
> Anthony Elder
> [EMAIL PROTECTED]
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
>
>
>
>
>
