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] Integrating Complete XML infoset support
Date Mon, 27 Jun 2005 05:22:39 GMT
No. OMDocument is a class

On 6/25/05, Aleksander Slominski <aslom@cs.indiana.edu> wrote:
> Venkat Reddy wrote:
> 
> >If no more objections are raised, lets conclude the discussion with
> >following decisions:
> >
> >1. Shift Child API from OMElement to OMContainer.
> >2. OMElement extends OMContainer
> >3. OMDocument implements OMContainer
> >
> >
> implements? OMDocument is not an interface?
> 
> alek
> 
> >4. Resolve Axis2 - 22 after these changes are made.
> >
> >OM'ers, if this is OK with you, Jaya will go ahead and make the
> >changes, and close the task of integrating Infoset support.
> >
> >- venkat
> >
> >
> >On 6/24/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> >
> >
> >>hmm... my assumption is that OMElementImpl will implement both
> >>OMContainer and OMElement, but not OMElement extending OMContainer. If
> >>OMElement extends OMContainer, then it is OK - no problem.
> >>
> >>On 6/24/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> >>
> >>
> >>>For example, userguide.clients.ClientUtil.getEchoOMElement() uses the
> >>>following syntax to build the message.
> >>>        OMFactory fac = OMAbstractFactory.getOMFactory();
> >>>        OMNamespace omNs =
> >>>fac.createOMNamespace("http://example1.org/example1", "example1");
> >>>        OMElement method = fac.createOMElement("echo", omNs);
> >>>        OMElement value = fac.createOMElement("Text", omNs);
> >>>        value.addChild(fac.createText(value, "Axis2 Echo String "));
> >>>        method.addChild(value);
> >>>
> >>>If the addChild method is moved from OMElement to OMContainer, this
> >>>syntax doesn't work. OMContainer will replace OMElement all over the
> >>>client programming. The other not-so-good alternative is to typecast
> >>>OMElement to OMElementImpl and then call addChild, because
> >>>OMElementImpl implements OMContainer.
> >>>
> >>>- venkat
> >>>
> >>>
> >>>
> >>>On 6/24/05, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> >>>
> >>>
> >>>>On Fri, 2005-06-24 at 13:03 +0530, Venkat Reddy wrote:
> >>>>
> >>>>
> >>>>>Alek,
> >>>>>
> >>>>>Like i said in the earlier thread on the same subject, there are
> >>>>>couple of issues if we move the child API from OMElement to a seperate
> >>>>>interface. The excerpt from my old mail:
> >>>>>
> >>>>>"The client API currently uses OMElement.addChild() to build the
> >>>>>message. Even if
> >>>>>we try to use setParent() instead of addChild() here, the user has
to
> >>>>>typecast the OMElement into OMElementImpl and pass it to setParent,
> >>>>>which is not elegant."
> >>>>>
> >>>>>Do have any ideas to resolve this? Until we get new ideas, here is
my
> >>>>>+1 for OMDocument extends OMElement.
> >>>>>
> >>>>>
> >>>>Maybe I didn't understand it (I didn't follow the previous thread
> >>>>carefully) but if there's an OmContainer interface containing
> >>>>addChild(), getChild() etc. etc., then if
> >>>>        interface OmElement extends OmContainer
> >>>>        interface OmDocument extends OmContainer
> >>>>etc. then I'm not clear why one needs to do a cast. Can you expand
> >>>>please Venkat?
> >>>>
> >>>>Sanjiva.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay
> 
> 


-- 
-- Jaya

Mime
View raw message