You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2005/06/22 10:11:32 UTC
[Axis2] Integrating Complete XML infoset support
Hi,
I remember Jayachandra wanted to integrate complete infest support, before
M2.
Since M2 is done and we gonna have an M3 soon, can u all integrate them.
Regards,
Chinthaka
Re: [Axis2] Integrating Complete XML infoset support
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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."
>
>
Venkat,
why not have interface OMElement extends XmlContainer, XmlContained
and interface OMDocument extends XmlContainer
where interface XmlContainer has all child meanagement methods (so they
are shared)
and XmlContained is used to mark that item has parent, like
public interface XmlContained{
public XmlContainer getParent();
public void setParent(XmlContainer el);
}
that should solve all problems?
>Do have any ideas to resolve this? Until we get new ideas, here is my
>+1 for OMDocument extends OMElement.
>
>
note also Infoset Document item has no parent! and that is significant!
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] Integrating Complete XML infoset support
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana 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?
>
>
>
that is exactly what I meant - I think I have described this before but
I send this example again in my reply to Venkat.
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2] Integrating Complete XML infoset support
Posted by Eran Chinthaka <ch...@opensource.lk>.
+1
> -----Original Message-----
> From: jayachandra [mailto:jayachandra@gmail.com]
> Sent: Monday, June 27, 2005 7:25 PM
> To: axis-dev@ws.apache.org
> 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 <ch...@opensource.lk> 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:vreddyp@gmail.com]
> > > Sent: Friday, June 24, 2005 4:55 PM
> > > To: axis-dev@ws.apache.org
> > > 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 <vr...@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 <vr...@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 <sa...@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.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> >
>
>
> --
> -- Jaya
Re: [Axis2] Integrating Complete XML infoset support
Posted by jayachandra <ja...@gmail.com>.
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 <ch...@opensource.lk> 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:vreddyp@gmail.com]
> > Sent: Friday, June 24, 2005 4:55 PM
> > To: axis-dev@ws.apache.org
> > 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 <vr...@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 <vr...@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 <sa...@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.
> > > > >
> > > > >
> > > > >
> > > >
> > >
>
>
>
>
--
-- Jaya
Re: [Axis2] Integrating Complete XML infoset support
Posted by Davanum Srinivas <da...@gmail.com>.
+1
On 6/27/05, jayachandra <ja...@gmail.com> wrote:
> On 6/27/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > On Mon, 2005-06-27 at 10:52 +0530, jayachandra wrote:
> > > No. OMDocument is a class
> >
> > ?? How come? OmElement is an interface so why isn't this??
> It was so since inception. May be as part of the ongoing refactoring
> we can have an interface OMDocument and a seperate Implementation
> class say OMDocumentImpl.java
> Even going by the infoset spec, we might want to have an interface for
> OMDocument, just the way we had it for OMElement, OMAttribute etc.
>
> Jaya
>
> >
> > Sanjiva.
> >
> >
> >
>
>
> --
> -- Jaya
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] Integrating Complete XML infoset support
Posted by jayachandra <ja...@gmail.com>.
On 6/27/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2005-06-27 at 10:52 +0530, jayachandra wrote:
> > No. OMDocument is a class
>
> ?? How come? OmElement is an interface so why isn't this??
It was so since inception. May be as part of the ongoing refactoring
we can have an interface OMDocument and a seperate Implementation
class say OMDocumentImpl.java
Even going by the infoset spec, we might want to have an interface for
OMDocument, just the way we had it for OMElement, OMAttribute etc.
Jaya
>
> Sanjiva.
>
>
>
--
-- Jaya
Re: [Axis2] Integrating Complete XML infoset support
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2005-06-27 at 10:52 +0530, jayachandra wrote:
> No. OMDocument is a class
?? How come? OmElement is an interface so why isn't this??
Sanjiva.
Re: [Axis2] Integrating Complete XML infoset support
Posted by jayachandra <ja...@gmail.com>.
No. OMDocument is a class
On 6/25/05, Aleksander Slominski <as...@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 <vr...@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 <vr...@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 <sa...@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
Re: [Axis2] Integrating Complete XML infoset support
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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 <vr...@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 <vr...@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 <sa...@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
RE: [Axis2] Integrating Complete XML infoset support
Posted by Eran Chinthaka <ch...@opensource.lk>.
+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:vreddyp@gmail.com]
> Sent: Friday, June 24, 2005 4:55 PM
> To: axis-dev@ws.apache.org
> 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 <vr...@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 <vr...@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 <sa...@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.
> > > >
> > > >
> > > >
> > >
> >
Re: [Axis2] Integrating Complete XML infoset support
Posted by Venkat Reddy <vr...@gmail.com>.
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 <vr...@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 <vr...@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 <sa...@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.
> > >
> > >
> > >
> >
>
Re: [Axis2] Integrating Complete XML infoset support
Posted by Venkat Reddy <vr...@gmail.com>.
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 <vr...@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 <sa...@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.
> >
> >
> >
>
Re: [Axis2] Integrating Complete XML infoset support
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Venkat Reddy 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.
>
well as far as I can tell it is going to work OK if OMElement extends
OMContainer ...
>OMContainer will replace OMElement all over the
>client programming.
>
why? for example?
>The other not-so-good alternative is to typecast
>OMElement to OMElementImpl and then call addChild, because
>OMElementImpl implements OMContainer.
>
>
i see no reason to do that.
alek
>- venkat
>
>
>
>On 6/24/05, Sanjiva Weerawarana <sa...@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
Re: [Axis2] Integrating Complete XML infoset support
Posted by Venkat Reddy <vr...@gmail.com>.
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 <sa...@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.
>
>
>
Re: [Axis2] Integrating Complete XML infoset support
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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.
Re: [Axis2] Integrating Complete XML infoset support
Posted by Venkat Reddy <vr...@gmail.com>.
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.
-- venkat
Re: [Axis2] Integrating Complete XML infoset support
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>On Thu, 2005-06-23 at 13:20 +0530, jayachandra wrote:
>
>
>>Resolution:
>>-----------------
>>Now this is left for the community to thoroughly discuss how we will
>>support full infoset. FYI, earlier before the release of M2 I worked
>>on this and found that making OMDocument extend OMElementImpl would
>>complement the lacking functionalities like child API, serialization
>>functionality etc. for OMDocument, without disturbing any of existing
>>code base.
>>
>>Yeah, the above fix gives the impression that OMDocument ISA OMElement
>>and that might not be correct. But if we all can churn and come out
>>with a better design I can use that to re-implement the infoset
>>support, as much as I can.
>>
>>
>
>This is how its done in most DOM impls too .. in fact IIRC Xerces DOM
>impl doesn't even complain if you add multiple child elements to the
>Document node! That's ok; that's a programmer error anyway :).
>
>So +1 for making OmDocument extend OmElement.
>
>
>
-0
why to do this *if* it can be done correctly and have API safeguards
against stupid mistake (what about horrors like OMDocument added inside
another OMElement ...)?
this is really not that difficult to get right - i did it in XPP3/5 and
it worked out just fine - children management function make sure that
only allowed content (comments, PIs etc) is inserted and there are
accessors for all content (see interface below).
alek
package org.xmlpull.v1.builder;
/**
* Represents
* <a
href="http://www.w3.org/TR/xml-infoset/#infoitem.document">Document
Information Item</a>
* .
*
* @version $Revision: 1.5 $
* @author <a href="http://www.extreme.indiana.edu/~aslom/">Aleksander
Slominski</a>
*/
public interface XmlDocument extends XmlContainer, Cloneable
{
//JDK15 covariant public XmlDocument clone() throws
CloneNotSupportedException
public Object clone() throws CloneNotSupportedException;
/**
* An ordered list of child information items, in document order.
* The list contains exactly one element information item.
* The list also contains one processing instruction information item
* for each processing instruction outside the document element,
* and one comment information item for each comment outside the
document element.
* Processing instructions and comments within the DTD are excluded.
* If there is a document type declaration,
* the list also contains a document type declaration information item.
*/
public Iterable children();
public XmlElement getDocumentElement();
public XmlElement requiredElement(XmlNamespace n, String name);
public XmlElement element(XmlNamespace n, String name);
public XmlElement element(XmlNamespace n, String name, boolean create);
/**
* An unordered set of notation information items,
* one for each notation declared in the DTD.
*/
public Iterable notations();
/**
* An unordered set of unparsed entity information items,
* one for each unparsed entity declared in the DTD.
*/
public Iterable unparsedEntities();
public String getBaseUri();
public String getCharacterEncodingScheme();
public void setCharacterEncodingScheme(String characterEncoding);
public Boolean isStandalone();
public String getVersion();
public boolean isAllDeclarationsProcessed();
// manipulate children
public void setDocumentElement(XmlElement rootElement);
public void addChild(Object child);
public void insertChild(int pos, Object child);
public void removeAllChildren();
public XmlComment newComment(String content);
public XmlComment addComment(String content);
public XmlDoctype newDoctype(String systemIdentifier, String
publicIdentifier);
public XmlDoctype addDoctype(String systemIdentifier, String
publicIdentifier);
//public XmlElement newDocumentElement(String name);
public XmlElement addDocumentElement(String name);
public XmlElement addDocumentElement(XmlNamespace namespace, String
name);
public XmlProcessingInstruction newProcessingInstruction(String
target, String content);
public XmlProcessingInstruction addProcessingInstruction(String
target, String content);
// manipulate unparsed entities
//addUnparsedEntity
public void removeAllUnparsedEntities();
// manipulate notations
public XmlNotation addNotation(String name,
String systemIdentifier,
String publicIdentifier,
String declarationBaseUri);
public void removeAllNotations();
}
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] Integrating Complete XML infoset support
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2005-06-23 at 13:20 +0530, jayachandra wrote:
> Resolution:
> -----------------
> Now this is left for the community to thoroughly discuss how we will
> support full infoset. FYI, earlier before the release of M2 I worked
> on this and found that making OMDocument extend OMElementImpl would
> complement the lacking functionalities like child API, serialization
> functionality etc. for OMDocument, without disturbing any of existing
> code base.
>
> Yeah, the above fix gives the impression that OMDocument ISA OMElement
> and that might not be correct. But if we all can churn and come out
> with a better design I can use that to re-implement the infoset
> support, as much as I can.
This is how its done in most DOM impls too .. in fact IIRC Xerces DOM
impl doesn't even complain if you add multiple child elements to the
Document node! That's ok; that's a programmer error anyway :).
So +1 for making OmDocument extend OmElement.
BTW are you working on JAX-WS stuff too? Cool!
Sanjiva.
Re: [Axis2] Integrating Complete XML infoset support
Posted by jayachandra <ja...@gmail.com>.
Yes Eran,
I'll kick start things...
Let me keep aside the work I did and discuss the issue afresh.
Background:
------------------
OM was designed expecting a typical SOAP message, which is a special
XML snippet whose syntax looks like
<xml declaration line>
<document element>
If we ignore the formal xml declaration line, essentially its just a
SINGLE document element (SOAPEnvelope) that is present with no other
siblings. With this assumption, the OMDocument implementation was
coded in a plain fashion having a datamember rootElement of type
OMElement. No child api is coded into OMDocument.
The Problem:
--------------------
XML infoset support invariably means support to comments, PI, DTDs
apart from the Document element. And in a general XML document all
these things may appear at the same level as the document element. And
things like PIs and Comments can appear multiple number of times also.
Now since all that we have in current OMDocument is support for just
the document element (i.e root element), I realize that with this
existing design of OMDocument we can't handle PI, DTD and document
level comments.
Resolution:
-----------------
Now this is left for the community to thoroughly discuss how we will
support full infoset. FYI, earlier before the release of M2 I worked
on this and found that making OMDocument extend OMElementImpl would
complement the lacking functionalities like child API, serialization
functionality etc. for OMDocument, without disturbing any of existing
code base.
Yeah, the above fix gives the impression that OMDocument ISA OMElement
and that might not be correct. But if we all can churn and come out
with a better design I can use that to re-implement the infoset
support, as much as I can.
Guys thoughts on this. Its time to investigate.
Thank you
Jayachandra
The work I did regarding this issue (going by the fix I described
above, under the resolution heading) can be availed from the location
http://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/ashu_jaya_venkat/xml_conformance.
JustTheModifiedFiles_Final folder hosts only the modified files
helping an easy and quick review.
On 6/22/05, Eran Chinthaka <ch...@opensource.lk> wrote:
>
>
> Hi,
>
>
>
> I remember Jayachandra wanted to integrate complete infest support, before
> M2.
>
>
>
> Since M2 is done and we gonna have an M3 soon, can u all integrate them.
>
>
>
> Regards,
>
> Chinthaka
--
-- Jaya