2008/6/13 Jeff MAURY <[EMAIL PROTECTED]>: > Just to finish the discussion: > > 1) I agree that XMLUnint will solve the problem > 2) I think the equals method should work on the component level because > Description is the component representation of the WSDL > 3) If the user wants to test equality at the element level, he should use > the toElement methods and use equals on the results.
That sounds like a nice idea, but both toElement() and toComponent() methods return 'this' ... so myDescription.toElement().equals(foo) will call the same equals() method on the same object as: myDescription.toComponent().equals(foo) but I can see your sentiment that the toElement() method should produce an object that effectively *is* the element model of the WSDL and so equals() method would test for equality at the element model level. I did have thoughts around the terminology we use - our meaning of the term "model" isn't quite the same (IMHO) as the meaning of the word "model" in the MVC pattern. I think if we starting thinking in terms of the MVC pattern then we would have a single model (in the MVC sense of the word) of the WSDL which would at least contain a representation of the XML (like DescriptionImpl does today) and optionally a calculated representation of WSDL in terms of what the spec calls *components*. This is pretty much what we have today in fact, except that we would just start saying we have *one* model. Then we would move to saying we have an "Element view" of the model and a "Component view" of the model. That way the equals() methods would be on the view and you would only ever compare an instance of one type of view of a WSDL with an instance of the same type of view of another WSDL. My only hesitation is that this is quite a significant change. Is it worth it just so that .equals() works? And we'd need hashCode() of course. It may provide further benefits - it would be easy enough to create other views on the model (if there was a use case for that). Regards, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
