Hi Jeremy, >I'm not proposing adding anything to the API
My concern is in adding complexity of the Woden API for other Woden implementations (say, an EMF based impl), which doesn't necessarily involve adding complexity to the interfaces. The functionality of the equals method really is part of the API as it defines an expected function from the method and other implementations will have to implement the method in a manner that produces the expected results in order to avoid breaking clients who use equals. >I guess the key question is: where is the requirement for object >equivalence? Do our users need to determine equality of two WSDL >components? Do they need to determine equality of two WSDL XML Infoset >trees. I think there's a good chance they will. I think you're right about this although I don't know the specific comparison requirements. Any idea if Axis2 relies in anyway on equivalence tests? Lawrence "Jeremy Hughes" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/22/2007 05:31 PM Please respond to [email protected] To [email protected] cc Subject Re: Woden API Review wiki page Hi Lawrence, On 22/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > Jeremy, > > I'm worried that creating separate impl classes for the component and > element models will add more complexity to Woden. We've already had > requests to reduce the complexity of the Woden model. What are you counting as the model here? Is it the impl classes or the API? I'm not proposing adding anything to the API - except removing the boolean equals(WSDLComponent) method on WSDLComponent, and for us to implement equals(Object) in our *Impl classes. So conceptually Woden remains the same. Agreed, from an implementation point of view there would be some additional complexity. But we don't get the 'equals' functionality for free. At the moment the equals method doesn't work for our classes. And while we're there we might want to implement hashCode() too so our *Impl objects can be put into HashMaps etc efficiently. If we merge the two APIs then we might still need a way of comparing the object representation of WSDL from an XML Infoset point of view and also from the component model point of view. So we might still need this capability but we'd need to implement it in a different way to equals(). Perhaps componentEquals() and xmlEquals() - but that feels really incongruous to me. I guess the key question is: where is the requirement for object equivalence? Do our users need to determine equality of two WSDL components? Do they need to determine equality of two WSDL XML Infoset trees. I think there's a good chance they will. > > Lawrence > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/22/2007 12:07 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Re: Woden API Review wiki page > > > > > > > One idea I have is to think in terms of the MVC pattern. The current > *Impl classes are the model, the *Element interfaces include > controller methods (add* etc). We have two views - the component view > and the element (XML infoset) view. > > Right now the *Impl classes directly implement the component and > element java interfaces. So there is only one equals() implementation > and that needs to cover both component and element views. > > If we separate the *Impl classes from those interfaces, by having a > lightweight 'component view' implementation and an 'element view' > implementation, then we can have a separate implementation of equals() > for each. The other methods will simple delegate straight into the > existing *Impl classes. > > This will be easier to talk about with some code to look at so I'll > put together a sample of what I mean. > > Cheers, > Jeremy > > On 22/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > Merging the Component and Element APIs will not solve the problem of > > implementing equals(Object) to determine logical equality. The object > > model will still contain Component model and Infoset data and equality > > between components does not necessarily mean their infosets are > > equivalent. Some component properties are derived by evaluating the > > attributes present in the infoset and applying certain rules. It's > > possible to have equivalent Component models created from different XML > > infosets. > > > > We could decide that equals(Object) applies to WSDL Component model > > equivalence only, but that does mean we could end up with two objects > with > > different infoset data being considered equal. We won't be able to use > > equals(Object) for checking equivalence in the WSDL infoset model. Maybe > > that doesn't matter. Maybe it's enough just to use the Component > > equivalence defined in the spec when comparing Woden WSDL objects via > > equals(Object). > > > > regards, > > John Kaputin > > > > > > [EMAIL PROTECTED] wrote on 21/11/2007 17:13:18: > > > > > One issue is the equals() method. As things stand there is an > > > equals(WSDLComponent) method on WSDLComponent interface and > > > implemented trivially on WSDLComponentImpl. Unfortunately if you > > > compare two DescriptionElement objects the equals(Object) method is > > > called which returns false. There is a fundamental problem with having > > > a single implementation class implementing the WSDLComponent and > > > WSDLElement interfaces. > > > > > > If I want to compare two DescriptionElement instances with each other > > > then equals(Object) needs to be implemented (by DescriptionImpl) and > > > that implementation needs to do the comparison at the XML infoset > > > level. > > > > > > If I want to compare two Description instances (ie at the component > > > model level) then equals(Object) needs to be implemented (by > > > DescriptionImpl) and that implementation needs to do the comparison at > > > the Component model level. > > > > > > There's a conflict here ... the equals() method doesn't know which one > > to do! > > > > > > So ... firstly, is object comparison something we wish to allow our > > > users to do. I think it would be useful and equals() is a fundamental > > > part of a well formed API. > > > > > > Not quite sure what the solution is right now though. > > > > > > Cheers, > > > Jeremy > > > > > > On 15/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > > > With Woden M8 in progress and (hopefully) a Woden 1.0 release to > > follow we > > > > need to think about stabilizing/finalizing the Woden API. The 1.0 > > release > > > > should define our 'committed' API. Some API issues have been or are > > being > > > > addressed via JIRAs. Some other issues may require more discussion > on > > the > > > > woden-dev mailing list before they're ready to track as JIRAs. > > > > > > > > To capture such issues and provide background info to prompt further > > > > discussion, I have created an API Review page on the Woden Wiki [1]. > > See > > > > the intro there for more details, read through the issues (2 so far) > > and > > > > post your ideas to the list. > > > > > > > > [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview > > > > > > > > regards, > > > > John Kaputin > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
