+1 We discussed this issue on today's Woden status call. (As a reminder, the call is open to all. Details can be found at [1].) John will implement the isEquivalentTo solution in a branch. We can then review the branch, see if revisions or another approach is required.
[1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Lawrence From: "John Kaputin (gmail)" <[EMAIL PROTECTED]> To: woden-dev@ws.apache.org Date: 07/08/2008 08:06 AM Subject: Re: equals method (was: Re: Questions about tests) How about I assign JIRA Woden-209 (which is about equivalence) to myself and implement a solution based on isEquivalentTo() and update the tests as necessary? I can work in a branch rather than trunk, so we can review it before committing to trunk. John. On Tue, Jul 8, 2008 at 4:52 PM, Jeremy Hughes <[EMAIL PROTECTED]> wrote: Arthur, I'm a bit confused. In a previous email in this thread you said: "I suggest using equals() to mean element equality" but below you're saying: "In general, it does not make sense to test two elements for equivalence." In any case, I'm starting to come round to the 'isEquivalentTo()' idea primarily because my proposal has a 'usability flaw'. If we were to implement component model equivalence in the equals() method of the org.apache.woden.internal.wsdl20.*Impl classes then this code does something unexpected: WSDLFactory factory = WSDLFactory.newInstance(); descElem1 = factory.newDescription(); descElem2 = factory.newDescription(); // because the Impl class implements both Description and // DescriptionElement and there can only be one Object equals(Object) // method, if we decide to implement it as comparing at the component // model level then the following line of code does something unexpected // (compares at the component model not the element model) if (descElem1.equals(descElem2)) ....... If what John summarizes your position to be [1] is correct then I'm +1 for that too. [1] http://markmail.org/message/iskbhuoseuxxcqsl Regards, Jeremy 2008/7/8 Arthur Ryman <[EMAIL PROTECTED]>: > Sagara, > > Equivalence is only defined for components in the WSDL 2.0 spec. In > general, it does not make sense to test two elements for equivalence. > If an element maps to a component then it could be compared for > equivalence. > > Note that not all elements in the info map to components. > > Therefore, we should only add isEquivalentTo() to the Component interface. > > -- Arthur > > On Mon, Jul 7, 2008 at 4:48 PM, Jeremy Hughes <[EMAIL PROTECTED]> wrote: >> Arthur, >> >> In this posting [1] I set out a few scenarios where .equals() would be >> useful for comparing components. I think XML / element model >> comparison will be less likely - I can see most applications would be >> manipulating WSDL at the component level. It really only needs XML / >> element model manipulation at the (de)serialization stage to get the >> WSDL into the correct file layout. I mentioned in the previous post >> that if there is a use case for comparing at the element model level >> then this is really equivalent to comparing at the XML level and can >> be done using something like XMLUnit on an xml stream / DOM object. >> >> [1] http://markmail.org/message/l6ors3ctmg4bjyco#query:+page:1+mid:l6ors3ctmg4bjyco+state:results >> >> Jeremy >> >> 2008/7/7 Arthur Ryman <[EMAIL PROTECTED]>: >>> >>> John, >>> >>> I suggest using equals() to mean element equality (on both the Element and >>> Component objects) and using isEquivalentTo() for component equivance. >>> >>> Is there any technical problem with that? >>> >>> Arthur Ryman, Technical Executive (IBM DE) >>> Project and Program Management, Rational Division >>> >>> phone: +1-905-413-3077, TL 313-3077 >>> assistant: +1-905-413-3831, TL 313-3831 >>> fax: +1-905-413-4920, TL 313-4920 >>> mobile: +1-416-939-5063 >>> >>> >>> "John Kaputin (gmail)" <[EMAIL PROTECTED]> >>> >>> 07/07/2008 01:10 PM >>> >>> Please respond to >>> woden-dev@ws.apache.org >>> To >>> woden-dev@ws.apache.org >>> cc >>> Subject >>> Re: equals method (was: Re: Questions about tests) >>> >>> >>> >>> >>> Arthur, >>> there was some discussion last month on the original thread [1]. Basically, >>> we have one set of Impl objects which implement two APIs (the Component and >>> Element APIs) and if we implement equals(Object) to test for logical >>> equivalence, there's confusion about which equivalence we are checking - >>> Component or Element. The spec just refers to Component equivalence and >>> Jeremy presented an argument in favour of implementing equals(Object) to >>> check for Component equivalence only. >>> >>> Currently, we declare the method WSDLComponent.equals(WSDLComponent) for the >>> Component API. It defaults to equality of object references in >>> WSDLComponentImpl and currently is only overridden in InterfaceImpl to check >>> for logical equivalence of Interface components (to handle Interface >>> inheritance). However, this equivalence checking for Interface inheritance >>> must still be implemented for InterfaceFault, InterfaceOperation, >>> InterfaceMessageReference and InterfaceFaultReference to complete the spec >>> requirements. >>> >>> I'm not so keen on equals(WSDLComponent) anymore. I think I prefer your >>> suggestion of WSDLComponent.isEquivalentTo(WSDLComponent). This would avoid >>> any confusion about what equals() methods mean in the Woden implementation. >>> It won't permit the use of collection methods like contains(), that rely on >>> a suitable implementation of equals(Object), but we don't use those methods >>> in the Woden implementation anyway. See how the equals(WSDLComponent) method >>> is currently used - we just loop through the collection of components, >>> checking each one for equivalence with equals(WSDLComponent). We could do >>> this just as well with an isEquivalentTo() method instead and it would >>> probably be more obvious too. >>> >>> [1] >>> http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200806.mbox/[EMAIL PROTECTED] >>> >>> regards, >>> John >>> >>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <[EMAIL PROTECTED]> wrote: >>> >>> Sagara, >>> >>> -1 on the use of the name Comparator. That should only be used for defining >>> a total ordering on objects, e.g. for when you sort them. >>> >>> Remind me why we can't have a standard equals() method? The topic of >>> component equivalence can be deferred and we can define an isEquivalentTo() >>> method later. >>> >>> Arthur Ryman, Technical Executive (IBM DE) >>> Project and Program Management, Rational Division >>> >>> phone: +1-905-413-3077, TL 313-3077 >>> assistant: +1-905-413-3831, TL 313-3831 >>> fax: +1-905-413-4920, TL 313-4920 >>> mobile: +1-416-939-5063 >>> >>> "Sagara Gunathunga" <[EMAIL PROTECTED]> >>> >>> 07/07/2008 12:02 PM >>> >>> Please respond to >>> woden-dev@ws.apache.org >>> >>> To >>> woden-dev@ws.apache.org >>> cc >>> Subject >>> Re: equals method (was: Re: Questions about tests) >>> >>> >>> >>> >>> >>> >>> Hi guys, >>> >>> I like to add some ideas to this discussion, it seems like we couldn't come >>> up with a good solution for this dilemma quickly. But with our 1.0 version >>> it is not a good thing to tell that we don't have a method to compare >>> equality of two WSDL component/element, it's always nice to have a solution >>> based on Object.equal() method , but in the users point of view most >>> important question is " is there any way to check equality of two WSDL >>> component/element ?? " . So my suggestion is to provide an alternative way >>> to compare WSDL component/elements until we find the ultimate solution. >>> >>> We can have a utility class called "WSDLComparator" to achieve this, >>> following method can be good candidate methods for this class. >>> >>> Public Boolean compare (WSDLCompnent com1, WSDLCompnent com2) >>> >>> Public Boolean compare (WSDLElemt ele2, WSDLElement ele2) >>> >>> >>> >>> Once we solve equal () method issue we can depreciate this class. >>> Meanwhile, I'm also facing this problem in my WSDLWritter test cases. I'm >>> planning to develop such a "WSDLComparator" class inside the test package >>> because there is no other way to compare WSDL components in my test cases. >>> >>> Thanks, >>> >>> On Wed, Jun 25, 2008 at 12:31 AM, Arthur Ryman <[EMAIL PROTECTED]> wrote: >>> >>> Jeremy, >>> >>> I don't know off hand if we have test cases for that, but we should add them >>> if they are missing, and contribute them to W3C. >>> >>> There are a couple of assertions related to equivalence [1], [2]. There are >>> a total of 5 test cases that cover these [3]. >>> >>> [1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceFault-1015 >>> [2] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020 >>> [3] http://dev.w3.org/2002/ws/desc/test-suite/Assertion-coverage.html >>> >>> Arthur Ryman, Technical Executive (IBM DE) >>> Project and Program Management, Rational Division >>> >>> phone: +1-905-413-3077, TL 313-3077 >>> assistant: +1-905-413-3831, TL 313-3831 >>> fax: +1-905-413-4920, TL 313-4920 >>> mobile: +1-416-939-5063 >>> >>> "Jeremy Hughes" <[EMAIL PROTECTED]> >>> Sent by: [EMAIL PROTECTED] >>> >>> 06/24/2008 09:55 AM >>> >>> Please respond to >>> woden-dev@ws.apache.org >>> >>> To >>> woden-dev@ws.apache.org >>> cc >>> Subject >>> Re: equals method (was: Re: Questions about tests) >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Arthur, >>> >>> 2008/6/24 Arthur Ryman <[EMAIL PROTECTED]>: >>>> >>>> Jeremy, >>>> >>>> The motivation for component equivalence was in fact the use case of >>>> "diamond" inheritence. Suppose you have four interfaces A, B, C, D, where >>>> B >>>> inherits A, C inherits A, and D inherits B and C. The D is getting all the >>>> operations from A twice, which is OK since they are equivalent. If B and C >>>> pointed to the same location for A there would be no problem, but if they >>>> point to different locations, then the parser must confirm that the >>>> definitions in each location are equivalent. >>>> >>>> A >>>> / \ >>>> B C >>>> \ / >>>> D >>>> >>> >>> I wonder if we have a test that looks like this where we B gets the A >>> document from a different location to where C gets it ... and also a >>> negative test variation on that where the two instances of the A >>> document are different. In woden today I believe an >>> InterfaceImpl.equals() will compare the object IDs as it delegates to >>> Object.equals() and not compare the content of the two objects >>> representing A. >>> >>>> Arthur Ryman, Technical Executive (IBM DE) >>>> Project and Program Management, Rational Division >>>> >>>> phone: +1-905-413-3077, TL 313-3077 >>>> assistant: +1-905-413-3831, TL 313-3831 >>>> fax: +1-905-413-4920, TL 313-4920 >>>> mobile: +1-416-939-5063 >>>> >>>> >>>> "Jeremy Hughes" <[EMAIL PROTECTED]> >>>> Sent by: [EMAIL PROTECTED] >>>> >>>> 06/24/2008 06:36 AM >>>> Please respond to >>>> woden-dev@ws.apache.org >>>> >>>> To >>>> woden-dev@ws.apache.org >>>> cc >>>> Subject >>>> equals method (was: Re: Questions about tests) >>>> >>>> >>>> >>>> >>>> Hi John, >>>> >>>> 2008/6/23 John Kaputin (gmail) <[EMAIL PROTECTED]>: >>>>> The WSDL 2 spec talks about equivalence between components. This is to do >>>>> with collapsing equivalent components derived from different parts of the >>>>> XML infoset into a single component in the Component model. I think there >>>>> are some assertions about it too. If I remember correctly, that was the >>>>> requirement behind having an equals() implementation that tested for the >>>>> logical equivalence of components and the equals(WSDLComponent) method >>>> >>>> I guess you're referring to section 2.15 of the core spec. I guess >>>> there isn't an interop as I don't think that would make sense - hence >>>> we haven't needed to get this to work so far. Also, I don't think we >>>> can be testing for equivalence in Woden today as the >>>> equals(WSDLComponent) method just delegates to Object.equals() >>>> >>>>> resulted because of the problem with implementing equals(Object) in an >>>>> Impl >>>>> class that implements both the Component and Element interfaces. >>>>> >>>>> For example, we wanted to override equals(Object) in DescriptionImpl, but >>>>> this implements both the Description component and the DescriptionElement >>>>> interfaces. The equivalence checking behavioiur for a Description >>>>> component >>>>> and a DescriptionElement are different, but at the DescriptionImpl level >>>>> we >>>>> can't tell which 'view' of the object the caller is seeing (component or >>>>> element). >>>> >>>> We could just define equals(Object) as comparing the two objects at >>>> the component model level. Then if you really want to compare at the >>>> XML level then you need to serialize both objects under comparison to >>>> XML and compare them using something like XMLUnit. We might be able to >>>> do something to simplify this with a layer on XMLUnit. >>>> >>>>> >>>>> We do need some form of equivalence checking to satisfy the spec and >>>>> while >>>>> implementing equals(WSDLComponent) across Woden might achieve this, it >>>>> will >>>>> break the transitivity of the Object equals() method as Jeremy says, >>>>> which >>>>> will limit the ability to make use of some aspects of Java (e.g. in the >>>>> collection classes). >>>> >>>> I've been trying to think of the use cases for the equals() method. >>>> For me it boils down to: does this WSDL (in object form) describe the >>>> same service as this other WSDL (in object form). Likely reasons you'd >>>> do this: >>>> >>>> a) you've read the WSDL from disc / URL twice and you want to see if >>>> they're the same. The DescriptionImpl objects will always be >>>> different, but the content will be equal. >>>> >>>> b) you've read WSDLs from two different locations and you want to see >>>> if they're the same - describe the same service, same service endpoint >>>> etc. Again the DescriptionImpl objects will have different object IDs. >>>> The WSDLs describe the same service if the component models are the >>>> same. The way in which a web service client interacts with the web >>>> service is the same whether it is using WSDL #1 or WSDL #2. i.e. there >>>> is nothing in the element model of the WSDLs that would cause the web >>>> service client to behave differently. If there was, then this should >>>> have been surfaced at the component model in some way. At least this >>>> has been my understanding, so if this is a false statement, please >>>> say. >>>> >>>> c) you've read WSDLs from two different locations and you want to see >>>> if they describe two different instances of the same web service - >>>> i.e. you have a choice of which the request should be sent to. For me >>>> this, and further variations on this theme (e.g. same web service, >>>> different transport) require the web service client to dig around in >>>> the WSDL a bit further than just calling equals(). I think this is >>>> possible today using the accessor methods we have today. >>>> >>>> d) you've read a WSDL and you want to split the WSDL into 2 - an >>>> interface and a service endpoint WSDL. Then you want to check that >>>> when you've done that, the result is semantically the same as what you >>>> started with. This is really a variation of b). >>>> >>>> So, based on this I think it the equals(Object) method should compare >>>> at the component model only. If there is a use case for comparing at >>>> the element model level then this is really equivalent to comparing at >>>> the XML level and can be done using something like XMLUnit on an xml >>>> stream / DOM object. >>>> >>>> So I propsose equals(Object) should compare at the component model only. >>>> >>>>> >>>>> Don't forget the issue still pending on the Woden wiki [1] about merging >>>>> the >>>>> Component and Element APIs into one API. This might simplify implementing >>>>> the equals(Object) method, but we will still need to test for Component >>>>> equivalence to satisfy the spec. >>>> >>>> What will merging the APIs really give us. I think that would be less >>>> intuitive. I guess I'd like to see how users of Woden wish to use it >>>> and what the shortfalls of the current APIs are. >>>> >>>>> >>>>> [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi >>>>> >>>>> regards, >>>>> John. >>>>> >>>>> On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <[EMAIL PROTECTED]> >>>>> wrote: >>>>>> >>>>>> 2008/6/13 Jeff MAURY <[EMAIL PROTECTED]>: >>>>>> > Just to finish the discussion: >>>>>> > >>>>>> > 1) I agree that XMLUnint will solve the problem >>>>>> > 2) I think the equals method should work on the component level >>>>>> > because >>>>>> > Description is the component representation of the WSDL >>>>>> > 3) If the user wants to test equality at the element level, he should >>>>>> > use >>>>>> > the toElement methods and use equals on the results. >>>>>> >>>>>> That sounds like a nice idea, but both toElement() and toComponent() >>>>>> methods return 'this' ... so >>>>>> >>>>>> myDescription.toElement().equals(foo) >>>>>> >>>>>> will call the same equals() method on the same object as: >>>>>> >>>>>> myDescription.toComponent().equals(foo) >>>>>> >>>>>> but I can see your sentiment that the toElement() method should >>>>>> produce an object that effectively *is* the element model of the WSDL >>>>>> and so equals() method would test for equality at the element model >>>>>> level. I did have thoughts around the terminology we use - our meaning >>>>>> of the term "model" isn't quite the same (IMHO) as the meaning of the >>>>>> word "model" in the MVC pattern. >>>>>> >>>>>> I think if we starting thinking in terms of the MVC pattern then we >>>>>> would have a single model (in the MVC sense of the word) of the WSDL >>>>>> which would at least contain a representation of the XML (like >>>>>> DescriptionImpl does today) and optionally a calculated representation >>>>>> of WSDL in terms of what the spec calls *components*. This is pretty >>>>>> much what we have today in fact, except that we would just start >>>>>> saying we have *one* model. Then we would move to saying we have an >>>>>> "Element view" of the model and a "Component view" of the model. That >>>>>> way the equals() methods would be on the view and you would only ever >>>>>> compare an instance of one type of view of a WSDL with an instance of >>>>>> the same type of view of another WSDL. >>>>>> >>>>>> My only hesitation is that this is quite a significant change. Is it >>>>>> worth it just so that .equals() works? And we'd need hashCode() of >>>>>> course. It may provide further benefits - it would be easy enough to >>>>>> create other views on the model (if there was a use case for that). >>>>>> >>>>>> Regards, >>>>>> Jeremy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Blog - ssagara.blogspot.com >>> Web - http://sagaras.awardspace.com/ >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
