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 > >>> [email protected] > >>> To > >>> [email protected] > >>> 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 > >>> [email protected] > >>> > >>> To > >>> [email protected] > >>> 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 > >>> [email protected] > >>> > >>> To > >>> [email protected] > >>> 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 > >>>> [email protected] > >>>> > >>>> To > >>>> [email protected] > >>>> 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] > >
