Oshani, I've been looking in depth at WODEN-44 regarding the refactoring of DOM/OMUtils into ElementSource. Some of these methods could be refactored and then some of the parseXXX methods in DOMWSDLReader and OMWSDLReader could be refactored into BaseWSDLReader, which would reduce the need for duplicate or similar code and would ensure better consistency of parsing behaviour across the implementations.
Later today I will attempt this in the WODEN-44 branch, starting first with the ElementSource refactoring then the DOMWSDLReader to BaseWSDLReader refactoring. If that is successful, we can then try removing the refactored parseXXX methods from OMWSDLReader and see if the methods inherited from BaseWSDLReader are suitable. I'll let you know when WODEN-44 is ready to try this last step. There might be a few problems to be sorted out along the way. For example: 1) OMWSDLReader calls OMElement.getChildElements, but there is no equivalent method in the DOM implementation - DOMWSDLReader calls DOMUtils.getFirstChildElement then, in a loop, it calls getNextSiblingElement. Although OMElement has a getFirstChild method it does not have a get-next-sibling method. The solution might be to add a getChildElements method to ElementSource and in DOMElementSource use the loop described above to return the child elements. Or perhaps OMElement does need a get-next-sibling type of method? 2) There are other OMElement or OMUtils methods that don't correspond to anything in ElementSource or DOMUtils. These are OMElement.getAllDeclaredNamespaces, OMUtils.getInputSource and OMUtils.getElement(String url). I think we should keep the ElementSource interface minimal - lowest common denominator of OMUtils and DOMUtils, not the union of both. So there might be some reader methods where it's better to override or implement in the concrete class, e.g. OMWSDLReader using the OMElement or even any remaining OMUtils methods directly, rather than adding extra implementation-specific methods to ElementSource. The same argument applies to DOMWSDLReader and DOMUtils. 3) One of the goals of the Woden programming model is type safety and we have deliberately used typed arrays in the API rather than Object collections like List. However, ElementSource currently has the method getAttributes() which returns a List. This method is not used yet, but probably will be needed in the refactored BaseWSDLReader for parsing namespace declarations and for parsing extension attributes. To retain type safety and consistency in the API I will have to change this to a typed array. The next question is what array type ..... see the next point. 4) ElementSource was originally just a wrapper for some underlying object representing an XML element (e.g. DOM Element or OMElement). By refactoring the DOMUtils methods into ElementSource it becomes an abstraction of those underlying objects. A method like getAttributes should return a typed array which suggests we also need a java type to represent XML attributes. i.e. an abstraction of an XML attribute. I don't really think ElementSource is a suitable name anymore as it has become more than just a wrapper for the original element object, so I don't think we should name this new XML attribute type 'AttributeSource'. I think I'll start with something like XMLElement and XMLAttribute instead (to avoid name clashes with DOM types) and I'll think about possible overlap with the existing XMLAttr types in org.apache.woden.xml. We can always change the names later if betters one emerge. regards, John Kaputin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
