Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] WSDL Interop issue - input/@name

Expand Messages
  • Bob Cunnings
    Hello, You are right, there is a conflict. Since the operations in the interop interface are unique, perhaps the wise thing to do is retreat to the safe
    Message 1 of 2 , Aug 27, 2001
    View Source
    • 0 Attachment
      Hello,

      You are right, there is a conflict. Since the operations in the "interop"
      interface are unique, perhaps the wise thing to do is retreat to the "safe
      harbor" in which no name is specified at all.

      If there is no objection, I'll make the changes.

      RC

      >
      > Note that the wsdl at [1] is the example of issue for the second case.
      > In this case for operation
      > echoString
      > we have portType/operation/input/@name = "echoString", but
      > binding/operation/input/@name is omitted. WSDL spec implicitly defaults
      > it to echoStringRequest which contradicts the input/@name value in
      > portType.
      > Hence, does everybody agree that wsdl at [1] is incorrect? Same for [2]
      >
      > [1] http://www.whitemesa.com/interop/InteropTest.wsdl
      > [2] http://www.whitemesa.com/interop/InteropTestB.wsdl
      >
      > If so - Bob, could you fix this?
      > Thank you.
      >
      > -----Original Message-----
      > From: Bob Cunnings [mailto:cunnings@...]
      > Sent: Monday, August 27, 2001 6:00 PM
      > To: soapbuilders@yahoogroups.com
      > Subject: Re: [soapbuilders] WSDL Interop issue
      >
      >
      > Hello,
      >
      > I do.
      >
      > Of course, if names are not specified for <input> and <output>
      > elements, the defaults are in force, and one is not troubled by
      > these concerns. This seems to be the best thing to do if the
      > operation names are unique. I've always thought the the names
      > should be specified only when operation names are repeated in the
      > portType, and the defaults won't suffice.
      >
      > Anyway, I agree that having a mismatch in name between <input>
      > or <output> elements defined for the same <operation> isn't
      > acceptable. If the names of the <input> and <output> elements are
      > significant (I think they are), then the "echoString" operation in the
      > <binding> doesn't map to the "echoString" operation that is found
      > in the <portType>, and that should be an error.
      >
      > RC
      >
      > > The following WSDL interop issue came up recently. Yann summed it up
      > > well in a recent email, so I'll just quote from him:
      > >
      > > In order to correlate an <operation> that appears under <portType>
      > > and <binding> WSDL 1.1 says to use the operation name attribute:
      > > <operation name=" ">. Furthermore, if the operation name attribute
      > > is not unique (eg. in the case of overloaded methods) then it says
      > > to use the name attribute on the <input> and <output> elements.
      > >
      > > So what do I do if operation name attribute is unique *and* the
      > > <input> and/or <output> name attributes do not match.
      > >
      > > If you read the spec literally then it seems you are to only look at
      > > input.name attribute only if operation is NOT unique. However it
      > > seems bad to ignore the fact that they are indeed different.
      > >
      > > For example is the following legal where input:name is not
      > > consistent between the two:
      > >
      > > <portType name="LiteralSoap">
      > > <operation name="echoString">
      > > <input message="s0:echoStringSoapIn" name="echoString" />
      > > <output message="s0:echoStringSoapOut" />
      > > </operation>
      > > </portType>
      > > <binding name="LiteralSoap">
      > > <operation name="echoString">
      > > <input name="echoStringRequest"/>
      > > <output/>
      > > </operation>
      > > </binding>
      > >
      > > Also this case where name attribute is simply not specified in the
      > > second case, meaning use the default which is echoStringRequest,
      > > meaning they are again different:
      > >
      > > <portType name="LiteralSoap">
      > > <operation name="echoString">
      > > <input message="s0:echoStringSoapIn" name="echoString" />
      > > <output message="s0:echoStringSoapOut" />
      > > </operation>
      > > </portType>
      > > <binding name="LiteralSoap">
      > > <operation name="echoString">
      > > <input />
      > > <output/>
      > > </operation>
      > > </binding>
      > >
      > > We believe that the above two WSDL fragments are illegal and should
      > > be rejected. Does everyone concur?
      > >
      > >
      > >
      > > -----------------------------------------------------------------
      > > This group is a forum for builders of SOAP implementations to discuss
      > implementation and interoperability issues. Please stay on-topic.
      > >
      > > To unsubscribe from this group, send an email to:
      > > soapbuilders-unsubscribe@yahoogroups.com
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss
      > implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss
      implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.