Good Effort Venkat. See my comments below. > > Not any burning issues; i'm just thinking aloud while going through the > code. > > - methods in OMElement and OMNode seem a bit mixed up. The > getter/setter methods for parent and siblings are available in OMNode > and they use OMElement and OMNode respectively. The getter/setter > methods for children are available on OMElement and they use OMNode.
The reason for this comes from the architecture of OM itself. Parent can only be an OMElement. OMElement can have OMNodes as children, which happens to be OMElement and OMText. We have to *fully* preserve the infoset. So we must maintain the text and elements order as well. So in the linked list implementation of OM we maintain these as a linked list of OMNodes. So getter/setter methods for children are always using OMNode. > Actually the confusion exists in SAAJ itself, where > javax.xml.soap.Node has setParent and getParent using SOAPElement. May > be i didn't understand the role of these two interfaces. However > org.w3c.dom seem to have clear roles for Node and Element. > > - setParent* methods SAAJ and adppendChild in DOM detach node from the > currrent parent first. OM implementations for these methods do not > detach node, and might end up in having multiple parents. Thankx. It was a mistake. I fixed that. Also > setParent looks redundant when we have appendChild methods doing the > same (applies to SAAJ also). Well you have the two ways to do the same thing. ;) > > - Almost all Impl classes "implement" OMConstants, may be to optimize > the access to the constants, but might reduce the clarity of code. Well I thought this is a normal practice. For example, rather than saying, OMConstants.XXXXX, XXXX is more straight forward. This came from my experience. One would say, this is some sort of misuse of interfaces. But ..... > > I think we are taking a bold step by defining OM as our own Axis > specific alternative to DOM and SAAJ to give us performance, which is > very refreshing and exciting too. Yeah, sure. I think we must be proud of our OM (at least I do). We are the first to implement an object model with differed building still with very good performance. We have proved that. The best way to predict the future is to invent it. (Thankx Alek ;)) And i'm sure we are also keeping an > eye on the stability of API at the same time. Definitely. -- Chinthaka > > - venkat
