The ideal thing would be to have OMNode support child API, but was not considered because OMText should not have children. I still favor shifting of child API to OMNode.
- venkat On 6/1/05, jayachandra <[EMAIL PROTECTED]> wrote: > 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 >
