+1 > -----Original Message----- > From: jayachandra [mailto:[EMAIL PROTECTED] > Sent: Monday, June 27, 2005 7:25 PM > To: [email protected] > Subject: Re: [Axis2] Integrating Complete XML infoset support > > Guys! > I'll take care of reflecting these changes. I'm more than half way. > I'm posting this just to ensure others won't waste their time redoing > the same. > > Jaya > > On 6/24/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > +1. > > > > Sorry I'm bit late to express my ideas. Anyway, this seems fine. > > > > Chinthaka. > > > > PS : "OM'ers" sounds bit weird :) > > > > > -----Original Message----- > > > From: Venkat Reddy [mailto:[EMAIL PROTECTED] > > > Sent: Friday, June 24, 2005 4:55 PM > > > To: [email protected] > > > Subject: Re: [Axis2] Integrating Complete XML infoset support > > > > > > 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 > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > -- Jaya
