- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Fri, 21 Mar 2003 11:00:35 -0800
- To: Arthur Ryman <ryman@ca.ibm.com>
- CC: Steve Tuecke <tuecke@mcs.anl.gov>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <3E7B6153.2040900@oracle.com>
Arthur Ryman wrote:
>Steve,
>
>I agree with you. If an expert like you reads a description and finds it
>unclear, then by definition it is unclear.
>
+ 1.
Yesterday after discussing the exact same case with one of my colleagues
at Oracle, even I was in doubt myself. The added note appears to
contradict the first paragraph definition as it is written.
--umit
>
>
>I think the first paragraph is actually wrong since it is too restrictive.
>It should be corrected as per the Hello12 example below.
>
>Arthur Ryman
>
>
>|---------+---------------------------->
>| | Steve Tuecke |
>| | <tuecke@mcs.anl.g|
>| | ov> |
>| | Sent by: |
>| | www-ws-desc-reque|
>| | st@w3.org |
>| | |
>| | |
>| | 03/21/2003 11:24 |
>| | AM |
>| | |
>|---------+---------------------------->
> >---------------------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: Arthur Ryman/Toronto/IBM@IBMCA |
> | cc: Steve Tuecke <tuecke@mcs.anl.gov>, www-ws-desc@w3.org, www-ws-desc-request@w3.org |
> | Subject: Re: Small language clarification in portType extension |
> | |
> | |
> >---------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>Arthur,
>
>Right. So you are not disagreeing with my comment that the language of
>this note is unclear in the diamond case. But you are adding that there is
>
>another case that is not correctly explained by this note as well? I
>agree. My understanding is the same as yours on the interpretation of your
>
>example.
>
>The "diamond inheritance case" I was bringing up is:
>
> <message name="stringMessage">
> <part name="name" type="xsd:string"/>
> </message>
>
> <interface name="A">
> <operation name="hello">
> <input message="tns:stringMessage" name="request"/>
> <output message="tns:stringMessage" name="response"/>
> </operation>
> </interface >
>
> <interface name="B" extends="tns:A">
> ...
> </interface >
>
> <interface name="C" extends="tns:A">
> ...
> </interface >
>
> <interface name="D" extends="tns:B tns:C">
> ...
> </interface >
>
>-Steve
>
>At 09:19 AM 3/21/2003, Arthur Ryman wrote:
>
>>Steve,
>>
>>I don't think the first paragraph is correct. My understanding is that it
>>is OK to derive from two different portTypes in the the same namespace
>>
>that
>
>>have the same named operations as long as the properties of the operations
>>are the same. This could occur even without diamond inheritance. For
>>example,
>>
>> <message name="stringMessage">
>> <part name="name" type="xsd:string"/>
>> </message>
>>
>> <interface name="Hello1">
>> <operation name="hello">
>> <input message="tns:stringMessage" name="request"/>
>> <output message="tns:stringMessage" name="response"/>
>> </operation>
>> </interface >
>>
>> <interface name="Hello2">
>> <operation name="hello">
>> <input message="tns:stringMessage" name="request"/>
>> <output message="tns:stringMessage" name="response"/>
>> </operation>
>> </interface >
>>
>> <interface name="Hello12" implements="tns:Hello1 tns:Hello2">
>> </interface >
>>
>>
>>Hello12 is OK and has a single operation hello, which it inherits from
>>
>both
>
>>Hello1 and Hello2. This is OK because the definitions of hello in Hello1
>>and Hello2 don't conflict.
>>
>>Arthur Ryman
>>
>>
>>|---------+---------------------------->
>>| | Steve Tuecke |
>>| | <tuecke@mcs.anl.g|
>>| | ov> |
>>| | Sent by: |
>>| | www-ws-desc-reque|
>>| | st@w3.org |
>>| | |
>>| | |
>>| | 03/20/2003 08:53 |
>>| | PM |
>>| | |
>>|---------+---------------------------->
>>
>> >
>>
>---------------------------------------------------------------------------------------------------------------------------------------------|
>
>> |
>> |
>> | To: www-ws-desc@w3.org
>> |
>> | cc:
>> |
>> | Subject: Small language clarification in portType
>>extension
>>|
>> |
>> |
>> |
>> |
>>
>> >
>>
>---------------------------------------------------------------------------------------------------------------------------------------------|
>
>>
>>
>>
>>Section 2.5.1 (The Port Type Operation Component) reads:
>>
>>"Note:
>>Due to the above rules, if two port types that have the same value for
>>their {target namespace} property also have one or more operations that
>>have the same value for their {name} property then those two port types
>>cannot both form part of the derivation chain of a derived port type.
>>Therefore it is considered good practice to ensure that operation names
>>within a namespace are unique, thus allowing such derivation to occur
>>without error."
>>
>>I suggest adding the word, "... if two DIFFERENT port types have the same
>>value ...". A reviewer questioned whether the current language meant that
>>the diamond inheritance case is illegal (B extends A, C extends A, D
>>extends B and C). But, of course, we specifically decided the diamond
>>inheritance case is legal, as reflected in the main normative text right
>>above this, which reads:
>>
>>"In cases where, due to a port type extending one or more other port
>>
>types,
>
>>two or more port type operation components have the same value for their
>>{name} and {target namespace} properties, then the component models of
>>those port type operation components MUST be equivalent (see 2.12
>>
>>Equivalence of components). If the port type operation components are
>>equivalent then they are considered to collapse into a component. It is an
>>error if two port type operation components have the same value for their
>>{name} and {target namespace} properties but are not equivalent."
>>
>>I think the addition of the word "different" would make the intent of this
>>note more clear.
>>
>>-Steve
>>
>
>
>
>
--
Umit Yalcinalp
Consulting Member of Technical Staff 400 Oracle Parkway
Oracle
Phone: +1 650 607 6154 Redwood Shores,
Email: umit.yalcinalp@oracle.com CA 94065, USA
Received on Friday, 21 March 2003 14:02:41 UTC