You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Sagara Gunathunga <sa...@gmail.com> on 2008/07/07 18:02:34 UTC
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 <ry...@ca.ibm.com> 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" <hu...@apache.org>*
> Sent by: jpjhughes@gmail.com
>
> 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 <ry...@ca.ibm.com>:
> >
> > 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" <hu...@apache.org>
> > Sent by: jpjhughes@gmail.com
> >
> > 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) <ja...@gmail.com>:
> >> 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 <hu...@apache.org>
> >> wrote:
> >>>
> >>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> >>> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
--
Sagara Gunathunga
Blog - ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ry...@ca.ibm.com>.
John,
Exactly.
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)" <ja...@gmail.com>
07/07/2008 11:45 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,
to summarize my understanding of your suggestion:
equals(Object) will just be used for object reference equality. That is,
the default behaviour of Object.equals(Object).
isEquivalentTo(WSDLComponent) will be used for checking logical
equivalence of components.
correct?
And the existing WSDLComponent.equals(WSDLComponent) method will be
deprecated and removed at some point, in favour of
isEquivalentTo(WSDLComponent).
regards,
John.
On Tue, Jul 8, 2008 at 10:10 AM, John Kaputin (gmail) <jakaputin@gmail.com
> wrote:
Arthur,
there's no technical problem with your suggestion. +1 from me.
John
On Tue, Jul 8, 2008 at 1:46 AM, Arthur Ryman <ry...@ca.ibm.com> wrote:
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)" <ja...@gmail.com>
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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
regards,
John
On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
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 <ry...@ca.ibm.com>:
>
> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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) <ja...@gmail.com>:
>> 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 <hu...@apache.org>
>> wrote:
>>>
>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>> > 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
--
Sagara Gunathunga
Blog - ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
Re: equals method (was: Re: Questions about tests)
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
Arthur,
to summarize my understanding of your suggestion:
equals(Object) will just be used for object reference equality. That is, the
default behaviour of Object.equals(Object).
isEquivalentTo(WSDLComponent) will be used for checking logical equivalence
of components.
correct?
And the existing WSDLComponent.equals(WSDLComponent) method will be
deprecated and removed at some point, in favour of
isEquivalentTo(WSDLComponent).
regards,
John.
On Tue, Jul 8, 2008 at 10:10 AM, John Kaputin (gmail) <ja...@gmail.com>
wrote:
> Arthur,
> there's no technical problem with your suggestion. +1 from me.
>
> John
>
>
> On Tue, Jul 8, 2008 at 1:46 AM, Arthur Ryman <ry...@ca.ibm.com> wrote:
>
>>
>> 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)" <ja...@gmail.com>*
>>
>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>> *<http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200806.mbox/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e>
>>
>> regards,
>> John
>>
>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <*r...@ca.ibm.com>>
>> 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" <**...@gmail.com>
>> *>*
>>
>> 07/07/2008 12:02 PM
>>
>>
>> Please respond to*
>> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>>
>> To
>> *woden-dev@ws.apache.org* <wo...@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 <*r...@ca.ibm.com>>
>> 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*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceFault-1015>
>> [2] *
>> http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020>
>> [3] *http://dev.w3.org/2002/ws/desc/test-suite/Assertion-coverage.html*<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" <**hughesj@apache.org* <hu...@apache.org>*>*
>> Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
>>
>> 06/24/2008 09:55 AM
>>
>>
>> Please respond to*
>> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>>
>> To
>> *woden-dev@ws.apache.org* <wo...@ws.apache.org> cc
>> Subject
>> Re: equals method (was: Re: Questions about tests)
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Arthur,
>>
>> 2008/6/24 Arthur Ryman <*ryman@ca.ibm.com* <ry...@ca.ibm.com>>:
>> >
>> > 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" <*hughesj@apache.org* <hu...@apache.org>>
>> > Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
>> >
>> > 06/24/2008 06:36 AM
>> > Please respond to
>> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
>> >
>> > To
>> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
>> > cc
>> > Subject
>> > equals method (was: Re: Questions about tests)
>> >
>> >
>> >
>> >
>> > Hi John,
>> >
>> > 2008/6/23 John Kaputin (gmail) <*j...@gmail.com>
>> >:
>> >> 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*<http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi>
>> >>
>> >> regards,
>> >> John.
>> >>
>> >> On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <*h...@apache.org>
>> >
>> >> wrote:
>> >>>
>> >>> 2008/6/13 Jeff MAURY <*j...@jeffmaury.com>
>> >:
>> >>> > 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: *woden-dev-unsubscribe@ws.apache.org*<wo...@ws.apache.org>
>> For additional commands, e-mail: *woden-dev-help@ws.apache.org*<wo...@ws.apache.org>
>>
>>
>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Blog - *ssagara.blogspot.com* <http://ssagara.blogspot.com/>
>> Web - *http://sagaras.awardspace.com/* <http://sagaras.awardspace.com/>
>>
>>
>
Re: equals method (was: Re: Questions about tests)
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
Arthur,
there's no technical problem with your suggestion. +1 from me.
John
On Tue, Jul 8, 2008 at 1:46 AM, Arthur Ryman <ry...@ca.ibm.com> wrote:
>
> 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)" <ja...@gmail.com>*
>
> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
> *<http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200806.mbox/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e>
>
> regards,
> John
>
> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <*r...@ca.ibm.com>>
> 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" <**...@gmail.com>
> *>*
>
> 07/07/2008 12:02 PM
>
>
> Please respond to*
> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>
> To
> *woden-dev@ws.apache.org* <wo...@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 <*r...@ca.ibm.com>>
> 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*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceFault-1015>
> [2] *
> http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020>
> [3] *http://dev.w3.org/2002/ws/desc/test-suite/Assertion-coverage.html*<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" <**hughesj@apache.org* <hu...@apache.org>*>*
> Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
>
> 06/24/2008 09:55 AM
>
>
> Please respond to*
> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>
> To
> *woden-dev@ws.apache.org* <wo...@ws.apache.org> cc
> Subject
> Re: equals method (was: Re: Questions about tests)
>
>
>
>
>
>
>
>
> Hi Arthur,
>
> 2008/6/24 Arthur Ryman <*ryman@ca.ibm.com* <ry...@ca.ibm.com>>:
> >
> > 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" <*hughesj@apache.org* <hu...@apache.org>>
> > Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
> >
> > 06/24/2008 06:36 AM
> > Please respond to
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> >
> > To
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> > cc
> > Subject
> > equals method (was: Re: Questions about tests)
> >
> >
> >
> >
> > Hi John,
> >
> > 2008/6/23 John Kaputin (gmail) <*j...@gmail.com>
> >:
> >> 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*<http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi>
> >>
> >> regards,
> >> John.
> >>
> >> On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <*h...@apache.org>
> >
> >> wrote:
> >>>
> >>> 2008/6/13 Jeff MAURY <*j...@jeffmaury.com>
> >:
> >>> > 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: *woden-dev-unsubscribe@ws.apache.org*<wo...@ws.apache.org>
> For additional commands, e-mail: *woden-dev-help@ws.apache.org*<wo...@ws.apache.org>
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - *ssagara.blogspot.com* <http://ssagara.blogspot.com/>
> Web - *http://sagaras.awardspace.com/* <http://sagaras.awardspace.com/>
>
>
Re: equals method (was: Re: Questions about tests)
Posted by Jeremy Hughes <hu...@apache.org>.
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 <ry...@ca.ibm.com>:
>
> 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)" <ja...@gmail.com>
>
> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>
> regards,
> John
>
> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
>
> 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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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 <ry...@ca.ibm.com>:
>>
>> 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" <hu...@apache.org>
>> Sent by: jpjhughes@gmail.com
>>
>> 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) <ja...@gmail.com>:
>>> 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 <hu...@apache.org>
>>> wrote:
>>>>
>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - ssagara.blogspot.com
> Web - http://sagaras.awardspace.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by Sagara Gunathunga <sa...@gmail.com>.
Hi Arthur,
I was basically focused on usage of that class, I agree with your
explanation about the name Comparator.
WSDLComponent.isEquivalentTo(WSDLComponent) method also pretty good but I
wonder how we check logical equivalence of two WSDLElements…? Whether we
will develop WSDLElement.isEquivalentTo(WSDLElement) method or any other way
…?
AFAIK it's possible that two equivalent Components could be derived from two
different WSDL infosets, in such cases Components level equivalence does not
imply element level equivalence.
I'm not think usage of equals () method for element equivalence is a good
option because, it is possible to make a confusion with Object.equl() method
. I mean what happen when we call WSDLComponent.equl() method ..? Because
is possible to have two different outcome for
WSDLComponent.isEquivalentTo(WSDLComponent) and
WSDLComponent.equl(WSDLComponent) methods.
Thanks,
On Mon, Jul 7, 2008 at 11:46 PM, Arthur Ryman <ry...@ca.ibm.com> wrote:
>
> 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)" <ja...@gmail.com>*
>
> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
> *<http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200806.mbox/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e>
>
> regards,
> John
>
> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <*r...@ca.ibm.com>>
> 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" <**...@gmail.com>
> *>*
>
> 07/07/2008 12:02 PM
>
>
> Please respond to*
> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>
> To
> *woden-dev@ws.apache.org* <wo...@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 <*r...@ca.ibm.com>>
> 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*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceFault-1015>
> [2] *
> http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020>
> [3] *http://dev.w3.org/2002/ws/desc/test-suite/Assertion-coverage.html*<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" <**hughesj@apache.org* <hu...@apache.org>*>*
> Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
>
> 06/24/2008 09:55 AM
>
>
> Please respond to*
> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>
> To
> *woden-dev@ws.apache.org* <wo...@ws.apache.org> cc
> Subject
> Re: equals method (was: Re: Questions about tests)
>
>
>
>
>
>
>
>
> Hi Arthur,
>
> 2008/6/24 Arthur Ryman <*ryman@ca.ibm.com* <ry...@ca.ibm.com>>:
> >
> > 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" <*hughesj@apache.org* <hu...@apache.org>>
> > Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
> >
> > 06/24/2008 06:36 AM
> > Please respond to
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> >
> > To
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> > cc
> > Subject
> > equals method (was: Re: Questions about tests)
> >
> >
> >
> >
> > Hi John,
> >
> > 2008/6/23 John Kaputin (gmail) <*j...@gmail.com>
> >:
> >> 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*<http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi>
> >>
> >> regards,
> >> John.
> >>
> >> On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <*h...@apache.org>
> >
> >> wrote:
> >>>
> >>> 2008/6/13 Jeff MAURY <*j...@jeffmaury.com>
> >:
> >>> > 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: *woden-dev-unsubscribe@ws.apache.org*<wo...@ws.apache.org>
> For additional commands, e-mail: *woden-dev-help@ws.apache.org*<wo...@ws.apache.org>
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - *ssagara.blogspot.com* <http://ssagara.blogspot.com/>
> Web - *http://sagaras.awardspace.com/* <http://sagaras.awardspace.com/>
>
>
--
Sagara Gunathunga
Blog - ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
Re: equals method (was: Re: Questions about tests)
Posted by Jeff MAURY <je...@jeffmaury.com>.
On 7/8/08, Arthur Ryman <ry...@ca.ibm.com> wrote:
>
>
> Jeremy,
>
> Let me clarify.
>
> When I said "element equality" I meant that they had the same object
> reference, i.e. an element object is only equal to itself.
>
> The default implementation of the equals() method on Object is to test the
> equality of the object references, i.e. are they the same object reference.
> In some cases this is too strict, e.g. when you are testing String or
> Integer objects, you can weaken this to test for value equality.
>
> You could define a kind of element value equality by comparing the
> attributes and content. But this definition is only useful if you have some
> application for it.
>
> However, for XML elements, I don't think value equality is very useful
> since the context of the element is usually important, i.e. it is a child
> and has a parent in general. So probably object reference equality is really
> want you want.
>
> In the WSDL 2.0 spec, the notion of equivalence is introduced, but this is
> only defined for components, not elements. Even here, component context is
> important. Some components have parent components and that is part of the
> test for equivalence. For example, you could have two distinct Interface
> components that happened to have an Operation component with the same name
> and signature, e.g. getSize(), but we don't consider them to be equivalent
> operations because they occur in difference contexts.
I don't think context evaluation matters here because the difference will be
achieved through the names of both interfaces that must be different. I
don't think that WSDL2.0 specs allow two interfaces of the same service
having the same name.
Regards
Jeff MAURY
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" <hu...@apache.org>*
> Sent by: jpjhughes@gmail.com
>
> 07/08/2008 04:52 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)
>
>
>
>
> 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 <ar...@gmail.com>:
> > 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 <hu...@apache.org>
> 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 <ry...@ca.ibm.com>:
> >>>
> >>> 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)" <ja...@gmail.com>
> >>>
> >>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
> >>>
> >>> regards,
> >>> John
> >>>
> >>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
> 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" <sa...@gmail.com>
> >>>
> >>> 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 <ry...@ca.ibm.com>
> 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" <hu...@apache.org>
> >>> Sent by: jpjhughes@gmail.com
> >>>
> >>> 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 <ry...@ca.ibm.com>:
> >>>>
> >>>> 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" <hu...@apache.org>
> >>>> Sent by: jpjhughes@gmail.com
> >>>>
> >>>> 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) <ja...@gmail.com>:
> >>>>> 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 <hu...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> >>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sagara Gunathunga
> >>>
> >>> Blog - ssagara.blogspot.com
> >>> Web - http://sagaras.awardspace.com/
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
--
La mélancolie c'est communiste
Tout le monde y a droit de temps en temps
La mélancolie n'est pas capitaliste
C'est même gratuit pour les perdants
La mélancolie c'est pacifiste
On ne lui rentre jamais dedans
La mélancolie oh tu sais ça existe
Elle se prend même avec des gants
La mélancolie c'est pour les syndicalistes
Il faut juste sa carte de permanent
Miossec (2006)
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.lastfm.fr/listen/user/jeffmaury/personal
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ry...@ca.ibm.com>.
Jeremy,
Let me clarify.
When I said "element equality" I meant that they had the same object
reference, i.e. an element object is only equal to itself.
The default implementation of the equals() method on Object is to test the
equality of the object references, i.e. are they the same object
reference. In some cases this is too strict, e.g. when you are testing
String or Integer objects, you can weaken this to test for value equality.
You could define a kind of element value equality by comparing the
attributes and content. But this definition is only useful if you have
some application for it.
However, for XML elements, I don't think value equality is very useful
since the context of the element is usually important, i.e. it is a child
and has a parent in general. So probably object reference equality is
really want you want.
In the WSDL 2.0 spec, the notion of equivalence is introduced, but this is
only defined for components, not elements. Even here, component context is
important. Some components have parent components and that is part of the
test for equivalence. For example, you could have two distinct Interface
components that happened to have an Operation component with the same name
and signature, e.g. getSize(), but we don't consider them to be equivalent
operations because they occur in difference contexts.
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" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
07/08/2008 04:52 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)
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 <ar...@gmail.com>:
> 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 <hu...@apache.org>
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 <ry...@ca.ibm.com>:
>>>
>>> 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)" <ja...@gmail.com>
>>>
>>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>>>
>>> regards,
>>> John
>>>
>>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
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" <sa...@gmail.com>
>>>
>>> 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 <ry...@ca.ibm.com>
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" <hu...@apache.org>
>>> Sent by: jpjhughes@gmail.com
>>>
>>> 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 <ry...@ca.ibm.com>:
>>>>
>>>> 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" <hu...@apache.org>
>>>> Sent by: jpjhughes@gmail.com
>>>>
>>>> 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) <ja...@gmail.com>:
>>>>> 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 <hu...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sagara Gunathunga
>>>
>>> Blog - ssagara.blogspot.com
>>> Web - http://sagaras.awardspace.com/
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
I have made the changes discussed in this thread in the woden209 branch and
would like those interested to review the changes prior to merging them into
trunk.
The WSDLComponent.equals method is deprecated and replaced with
WSLDComponent.isEquivalentTo. So far I have just replaced the existing
references to the equals method with calls to isEquivalentTo. There is
still further implementation of equivalence checking to be done for some of
the components (i.e. more implementations of isEquivalentTo are required).
regards,
John.
On Tue, Jul 8, 2008 at 11:57 PM, Lawrence Mandel <lm...@ca.ibm.com> wrote:
> +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)" <ja...@gmail.com>
> 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 <hu...@apache.org> 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 <ar...@gmail.com>:
> > 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 <hu...@apache.org>
> 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 <ry...@ca.ibm.com>:
> >>>
> >>> 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)" <ja...@gmail.com>
> >>>
> >>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>
> >>>
> >>> regards,
> >>> John
> >>>
> >>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
> 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" <sa...@gmail.com>
> >>>
> >>> 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 <ry...@ca.ibm.com>
> 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" <hu...@apache.org>
> >>> Sent by: jpjhughes@gmail.com
> >>>
> >>> 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 <ry...@ca.ibm.com>:
> >>>>
> >>>> 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" <hu...@apache.org>
> >>>> Sent by: jpjhughes@gmail.com
> >>>>
> >>>> 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) <ja...@gmail.com>:
> >>>>> 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 <hu...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> >>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sagara Gunathunga
> >>>
> >>> Blog - ssagara.blogspot.com
> >>> Web - http://sagaras.awardspace.com/
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
Re: equals method (was: Re: Questions about tests)
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
+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)" <ja...@gmail.com>
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 <hu...@apache.org> 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 <ar...@gmail.com>:
> 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 <hu...@apache.org>
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 <ry...@ca.ibm.com>:
>>>
>>> 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)" <ja...@gmail.com>
>>>
>>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>>>
>>> regards,
>>> John
>>>
>>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
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" <sa...@gmail.com>
>>>
>>> 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 <ry...@ca.ibm.com>
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" <hu...@apache.org>
>>> Sent by: jpjhughes@gmail.com
>>>
>>> 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 <ry...@ca.ibm.com>:
>>>>
>>>> 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" <hu...@apache.org>
>>>> Sent by: jpjhughes@gmail.com
>>>>
>>>> 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) <ja...@gmail.com>:
>>>>> 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 <hu...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sagara Gunathunga
>>>
>>> Blog - ssagara.blogspot.com
>>> Web - http://sagaras.awardspace.com/
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
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 <hu...@apache.org> 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 <ar...@gmail.com>:
> > 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 <hu...@apache.org>
> 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 <ry...@ca.ibm.com>:
> >>>
> >>> 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)" <ja...@gmail.com>
> >>>
> >>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
> >>>
> >>> regards,
> >>> John
> >>>
> >>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
> 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" <sa...@gmail.com>
> >>>
> >>> 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 <ry...@ca.ibm.com>
> 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" <hu...@apache.org>
> >>> Sent by: jpjhughes@gmail.com
> >>>
> >>> 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 <ry...@ca.ibm.com>:
> >>>>
> >>>> 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" <hu...@apache.org>
> >>>> Sent by: jpjhughes@gmail.com
> >>>>
> >>>> 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) <ja...@gmail.com>:
> >>>>> 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 <hu...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> >>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sagara Gunathunga
> >>>
> >>> Blog - ssagara.blogspot.com
> >>> Web - http://sagaras.awardspace.com/
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
Re: equals method (was: Re: Questions about tests)
Posted by Jeff MAURY <je...@jeffmaury.com>.
I don't think the point of having a WSDLComparator will fix the point
because component and element are the same object in the current
implementation so in order to distinct them you must have a separate method.
Maybe we should adapt the decorator pattern when we return the element so
that we can distinguish the equals method ?
Regards
Jeff MAURY
On Tue, Jul 8, 2008 at 10:52 AM, Jeremy Hughes <hu...@apache.org> 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 <ar...@gmail.com>:
> > 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 <hu...@apache.org>
> 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 <ry...@ca.ibm.com>:
> >>>
> >>> 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)" <ja...@gmail.com>
> >>>
> >>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
> >>>
> >>> regards,
> >>> John
> >>>
> >>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com>
> 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" <sa...@gmail.com>
> >>>
> >>> 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 <ry...@ca.ibm.com>
> 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" <hu...@apache.org>
> >>> Sent by: jpjhughes@gmail.com
> >>>
> >>> 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 <ry...@ca.ibm.com>:
> >>>>
> >>>> 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" <hu...@apache.org>
> >>>> Sent by: jpjhughes@gmail.com
> >>>>
> >>>> 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) <ja...@gmail.com>:
> >>>>> 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 <hu...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> >>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sagara Gunathunga
> >>>
> >>> Blog - ssagara.blogspot.com
> >>> Web - http://sagaras.awardspace.com/
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
--
La mélancolie c'est communiste
Tout le monde y a droit de temps en temps
La mélancolie n'est pas capitaliste
C'est même gratuit pour les perdants
La mélancolie c'est pacifiste
On ne lui rentre jamais dedans
La mélancolie oh tu sais ça existe
Elle se prend même avec des gants
La mélancolie c'est pour les syndicalistes
Il faut juste sa carte de permanent
Miossec (2006)
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.lastfm.fr/listen/user/jeffmaury/personal
Re: equals method (was: Re: Questions about tests)
Posted by Jeremy Hughes <hu...@apache.org>.
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 <ar...@gmail.com>:
> 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 <hu...@apache.org> 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 <ry...@ca.ibm.com>:
>>>
>>> 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)" <ja...@gmail.com>
>>>
>>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>>>
>>> regards,
>>> John
>>>
>>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
>>>
>>> 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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
>>> Sent by: jpjhughes@gmail.com
>>>
>>> 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 <ry...@ca.ibm.com>:
>>>>
>>>> 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" <hu...@apache.org>
>>>> Sent by: jpjhughes@gmail.com
>>>>
>>>> 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) <ja...@gmail.com>:
>>>>> 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 <hu...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sagara Gunathunga
>>>
>>> Blog - ssagara.blogspot.com
>>> Web - http://sagaras.awardspace.com/
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ar...@gmail.com>.
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 <hu...@apache.org> 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 <ry...@ca.ibm.com>:
>>
>> 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)" <ja...@gmail.com>
>>
>> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>>
>> regards,
>> John
>>
>> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
>>
>> 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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
>> Sent by: jpjhughes@gmail.com
>>
>> 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 <ry...@ca.ibm.com>:
>>>
>>> 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" <hu...@apache.org>
>>> Sent by: jpjhughes@gmail.com
>>>
>>> 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) <ja...@gmail.com>:
>>>> 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 <hu...@apache.org>
>>>> wrote:
>>>>>
>>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>>> > 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: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>>
>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Blog - ssagara.blogspot.com
>> Web - http://sagaras.awardspace.com/
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ry...@ca.ibm.com>.
Jeremy,
Is unit testing the main motivation for the equals() method for elements?
If so, I agree this should be done at the DOM level, i.e. independent of
WSDL.
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" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
07/07/2008 04:48 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,
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 <ry...@ca.ibm.com>:
>
> 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)" <ja...@gmail.com>
>
> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>
> regards,
> John
>
> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
>
> 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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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 <ry...@ca.ibm.com>:
>>
>> 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" <hu...@apache.org>
>> Sent by: jpjhughes@gmail.com
>>
>> 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) <ja...@gmail.com>:
>>> 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 <hu...@apache.org>
>>> wrote:
>>>>
>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - ssagara.blogspot.com
> Web - http://sagaras.awardspace.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by Jeremy Hughes <hu...@apache.org>.
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 <ry...@ca.ibm.com>:
>
> 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)" <ja...@gmail.com>
>
> 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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
>
> regards,
> John
>
> On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
>
> 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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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 <ry...@ca.ibm.com>:
>>
>> 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" <hu...@apache.org>
>> Sent by: jpjhughes@gmail.com
>>
>> 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) <ja...@gmail.com>:
>>> 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 <hu...@apache.org>
>>> wrote:
>>>>
>>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>>> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - ssagara.blogspot.com
> Web - http://sagaras.awardspace.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ry...@ca.ibm.com>.
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)" <ja...@gmail.com>
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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
regards,
John
On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>
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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
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 <ry...@ca.ibm.com>:
>
> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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) <ja...@gmail.com>:
>> 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 <hu...@apache.org>
>> wrote:
>>>
>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>> > 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
--
Sagara Gunathunga
Blog - ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
Re: equals method (was: Re: Questions about tests)
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
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/%3c19a9f6be0806120420g677e1b5bwab97ffc984828d8c@mail.gmail.com%3e
regards,
John
On Tue, Jul 8, 2008 at 12:31 AM, Arthur Ryman <ry...@ca.ibm.com> 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" <sa...@gmail.com>*
>
> 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 <*r...@ca.ibm.com>>
> 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*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceFault-1015>
> [2] *
> http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020*<http://www.w3.org/TR/2007/REC-wsdl20-20070626/#InterfaceOperation-1020>
> [3] *http://dev.w3.org/2002/ws/desc/test-suite/Assertion-coverage.html*<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" <**hughesj@apache.org* <hu...@apache.org>*>*
> Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
>
> 06/24/2008 09:55 AM
>
>
> Please respond to*
> **woden-dev@ws.apache.org* <wo...@ws.apache.org>
>
> To
> *woden-dev@ws.apache.org* <wo...@ws.apache.org> cc
> Subject
> Re: equals method (was: Re: Questions about tests)
>
>
>
>
>
>
> Hi Arthur,
>
> 2008/6/24 Arthur Ryman <*ryman@ca.ibm.com* <ry...@ca.ibm.com>>:
> >
> > 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" <*hughesj@apache.org* <hu...@apache.org>>
> > Sent by: *jpjhughes@gmail.com* <jp...@gmail.com>
> >
> > 06/24/2008 06:36 AM
> > Please respond to
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> >
> > To
> > *woden-dev@ws.apache.org* <wo...@ws.apache.org>
> > cc
> > Subject
> > equals method (was: Re: Questions about tests)
> >
> >
> >
> >
> > Hi John,
> >
> > 2008/6/23 John Kaputin (gmail) <*j...@gmail.com>
> >:
> >> 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*<http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi>
> >>
> >> regards,
> >> John.
> >>
> >> On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <*h...@apache.org>
> >
> >> wrote:
> >>>
> >>> 2008/6/13 Jeff MAURY <*j...@jeffmaury.com>
> >:
> >>> > 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: *woden-dev-unsubscribe@ws.apache.org*<wo...@ws.apache.org>
> For additional commands, e-mail: *woden-dev-help@ws.apache.org*<wo...@ws.apache.org>
>
>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - *ssagara.blogspot.com* <http://ssagara.blogspot.com/>
> Web - *http://sagaras.awardspace.com/* <http://sagaras.awardspace.com/>
>
Re: equals method (was: Re: Questions about tests)
Posted by Arthur Ryman <ry...@ca.ibm.com>.
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" <sa...@gmail.com>
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 <ry...@ca.ibm.com> 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" <hu...@apache.org>
Sent by: jpjhughes@gmail.com
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 <ry...@ca.ibm.com>:
>
> 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" <hu...@apache.org>
> Sent by: jpjhughes@gmail.com
>
> 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) <ja...@gmail.com>:
>> 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 <hu...@apache.org>
>> wrote:
>>>
>>> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
>>> > 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
--
Sagara Gunathunga
Blog - ssagara.blogspot.com
Web - http://sagaras.awardspace.com/