W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2006

Re: Does {parent} affect equivalence of components for Interface Extension?

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Tue, 25 Apr 2006 10:00:52 -0400
To: woden-dev@ws.apache.org
Cc: "John Kaputin" <KAPUTIN@uk.ibm.com>, woden-dev@ws.apache.org, www-ws-desc@w3.org
Message-ID: <OFECB8CC33.3ECAD885-ON8525715B.004A4356-8525715B.004CFB51@ca.ibm.com>
John,

The answer is YES.

This issue came up early in the spec [1]. The intuition is that nested 
components are local, so if two happen to look the same, that is an 
accident. Every nested component should have a unique parent. So if the 
parents differ, the nested components differ.

We introduced the {parent} property specifically to make nested components 
inequivalent when they have inequivalent parents. In your example, the two 
foo Interface Operations components are inequivalent.

If we didn't have the {parent} property then we'd have to collapse the foo 
Interface Operations into a single component. That component would 
therefore have two parents - not what we intended. They should be local.

The reason that equivalence was introduced into the spec was to allow for 
the same top level components to be included in the component model along 
two or more paths, and not generate an error. This type of situation could 
arise in "diamond" inheritance.

  A
 / \
B   C
 \ /
  D

For example, if A extends B and C, and both B and C extend D, then you 
could have the situation where B.wsdl includes D.wsdl, and C.wsdl includes 
D.wsdl. Then when A.wsdl includes B.wsdl and C.wsdl, you'd end up with two 
copies of D. We want to allow this so we defined component equivalence.

The intension of component equivalence was to allow top-level components 
to be flexibly placed in documents. So really we only need to start the 
test at the top-level component and then traverse downward, i.e. we should 
have tested the parent component before we test the nested component.

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC83

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



"John Kaputin (gmail)" <jakaputin@gmail.com> 
04/25/2006 06:14 AM
Please respond to
woden-dev@ws.apache.org


To
www-ws-desc@w3.org
cc
woden-dev@ws.apache.org, "John Kaputin" <KAPUTIN@uk.ibm.com>
Subject
Does {parent} affect equivalence of components for Interface Extension?






I'm implementing interface extension in Apache Woden but I'm a bit 
confused on equivalence of components nested within interfaces when 
interface extension is involved.  I'd like clarification on how the 
{parent} property is used when testing equivalence of components and when 
collapsing equivalent components to a single component.

InterfaceOperation in Part 1 Section 2.4 says:
In cases where, due to an interface extending one or more other 
interfaces, two or more Interface Operation components have the same value 
for their {name} property, then the component models of those Interface 
Operation components MUST be equivalent (see 2.17 Equivalence of 
Components).? If the Interface Operation components are equivalent then 
they are considered to collapse into a single component.

Consider the case where two operations are defined in different 
interfaces, with one interface extending the other, and the operations are 
equivalent, except their {parent} property because they are declared in 
different interfaces. 

Here's some example XML:

<description ...tns=.... >
    <interface name="betty">
        <operation name="foo" pattern="urn:bar"/>
     </interface>
    <interface name="boop" extends="tns:betty">
        <operation name="foo" pattern="urn:bar"/>
     </interface>
</description>


Does the difference in {parent} mean that the two "foo" operations are not 
equivalent, or should {parent} be ignored when testing for equivalence 
here?

If {parent} should be ignored, perhaps Section 2.17 Equivalence of 
Components does not strictly apply (i.e. it says all properties should be 
equal).  But if {parent} should be ignored for equivalence testing in this 
case, then when collapsing the two equivalent operations into one 
InterfaceOperation component what will be the value of {parent} ("betty" 
or "boop")?

On the other hand, if {parent} should be part of the equivalence test then 
these two operations can never be equivalent and the paragraph in Section 
2.4 is perhaps unnecessary.

thanks,
John Kaputin.
Received on Tuesday, 25 April 2006 14:01:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:39 GMT