axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jayachandra <jayachan...@gmail.com>
Subject Re: [Axis2] Need for children API for OMDocument
Date Wed, 01 Jun 2005 07:29:41 GMT
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