Yeah! that's a wise way rather than extending OMElement. Apart being more clear on the readability front it also reduces unnecessary placeholders from creeping into OMDocument.
Jaya On 6/1/05, Aleksander Slominski <[EMAIL PROTECTED]> wrote: > jayachandra wrote: > > >Can someone respond on this, plz. > > > > > why not model it exactly as it is in XML Infoset - so have children API > but do not extend OMElement just duplicate it (AFAICT Document is not > Element ...) > http://www.w3.org/TR/xml-infoset/#infoitem.document > > alek > > >Thanks > >Jaya > > > >On 5/31/05, jayachandra <[EMAIL PROTECTED]> wrote: > > > > > >>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 > >> > >> > >> > > > > > > > > > > > -- > The best way to predict the future is to invent it - Alan Kay > > -- -- Jaya
