Hi devs, I have two suggestions regarding OMDocument
First - a trivial one: --------------------------- It lacks an interface definition in the package org.apache.axis.om and a direct implementation class with name OMDocument.java is coded in the o.a.a.om.impl.llom package. In line with how rest of the code is arranged, I suggest we have in o.a.a.om package an interface with name OMDocument.java listing out the setter and getter methods for rootElement. And in the OMFactory interface we will add an extra signature something like createOMDocument so as to enable other than llom factory to be able to provide OMDocument implementation. Let the implementation class in impl.llom package be named as OMDocumentImpl.java Second - this is a critical design issue: -------------------------------------------------------- Looking at the current OMDocument support I've realized that it doesn't have a child navigation API. We might be doing away without it as far as soap processing is considered. But without the child navigation API in it, XMLInfoset can never be fully supported because in an XML document other than the unique root element, at the same level we can have several other nodes like documentation comments, processing instructions, DTD element etc. Enabling child API in OMDocument, implementation wise is not any difficult. It can be just making it extend OMElement. Something like public interface OMDocument extends OMElement ; Semantically if the above looks confusing and weird (OMDocument being an OMElement !!??!!), alternatively we can copy paste the already coded child API functionality of OMElementImpl into OMDocumentImpl letting OMDocument to stand on its own without extending any other interface. Also, performance wise these changes are not going to add any significant overhead. Anticipating thoughts, ideas, suggestions Regards Jaya
