Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: domain of vreddyp@gmail.com designates
 64.233.170.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hT9DGuN0kfeTzzvYw+pQ+qT/c9bIAUKdRyqZZvaTZbzA47fmPflyYbcvuFp/rD4ijiWVV/PjMqaInycsAgW4k6sZh10/2Nxbtoiz5kKfRJ9yT2EPtnphxEt78myK5+6Vohv9zR0Ea+oLUnTFv9FtW8XWB0zGNN8qDE66z4qnvjI=
Message-ID: <fadf6631050601061112365dd0@mail.gmail.com>
Date: Wed, 1 Jun 2005 18:41:10 +0530
From: Venkat Reddy <vreddyp@gmail.com>
Reply-To: Venkat Reddy <vreddyp@gmail.com>
To: axis-dev@ws.apache.org, jayachandra <jayachandra@gmail.com>
Subject: Re: [Axis2] Need for children API for OMDocument
In-Reply-To: <57023d1305060100292cd5b699@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <57023d1305053022301a7ea38f@mail.gmail.com>
	 <57023d1305053123221181ea2b@mail.gmail.com>
	 <429D5E6E.3020100@cs.indiana.edu>
	 <57023d1305060100292cd5b699@mail.gmail.com>

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.
>=20
> Jaya
>=20
> 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 an=
d
> > >>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 nam=
e
> > >>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 i=
t
> > >>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
> >
> >
>=20
>=20
> --
> -- Jaya
>