axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venkat Reddy <vred...@gmail.com>
Subject Re: [Axis2] Need for children API for OMDocument
Date Wed, 01 Jun 2005 13:11:10 GMT
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 <jayachandra@gmail.com> 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 <aslom@cs.indiana.edu> 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 <jayachandra@gmail.com> 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
>

Mime
View raw message