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]
