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 jayachandra <ja...@gmail.com> on 2005/06/01 08:22:37 UTC
Re: [Axis2] Need for children API for OMDocument
Guys!
Can someone respond on this, plz.
Thanks
Jaya
On 5/31/05, jayachandra <ja...@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
>
--
-- Jaya
Re: [Axis2] Need for children API for OMDocument
Posted by Venkat Reddy <vr...@gmail.com>.
I suggest we go with Document extend OMElement to resolve this until
next refactoring of OM. WDYT?
On 6/3/05, Venkat Reddy <vr...@gmail.com> wrote:
> just saw some more issues if we go with new Interface.
>
> The client API 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.
>
> If we add a new method SOAPFactory.createOMParent(), then the entire
> client API has to deal with OMParent objects instead of OMElement
> objects while building the message, which looks weird.
>
> - Venkat
>
>
> On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> > Didn't I gave my +1 for this. Ok here goes, +1 ;).
> >
> > -- Chinthaka
> >
> > > -----Original Message-----
> > > From: Venkat Reddy [mailto:vreddyp@gmail.com]
> > > Sent: Thursday, June 02, 2005 10:55 AM
> > > To: axis-dev@ws.apache.org
> > > Subject: Re: [Axis2] Need for children API for OMDocument
> > >
> > > Not another class, but OMElementImpl need to implement the new
> > > interface and all the child API be moved from OMElement to OMParent.
> > > Also note that OMNode.setParent() now receives OMPraent, instead of
> > > OMElement.
> > >
> > > So the result is - OMDocument now implements only child navigation API
> > > and avoids stuff like namaespaces and attributes. +1.
> > >
> > > - venkat
> > >
> > > On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> > > > I'm ok with having an "interface" for parent, but not another class.
> > > >
> > > > -- Chinthaka
> > > >
> > > > > -----Original Message-----
> > > > > From: jayachandra [mailto:jayachandra@gmail.com]
> > > > > Sent: Wednesday, June 01, 2005 7:32 PM
> > > > > To: axis-dev@ws.apache.org
> > > > > Subject: Re: [Axis2] Need for children API for OMDocument
> > > > >
> > > > > While duplicating the child API into OMDocument I got stuck at
> > > something.
> > > > > The addChild() method of in turn tries to setParent(), and the
> > > > > datamember parent is rigidly typed to be an OMElement only.
> > > > > /**
> > > > > * Field parent
> > > > > */
> > > > > protected OMElementImpl parent;
> > > > >
> > > > > Now that OMDocument can also be a parent other than just OMElement, my
> > > > > suggestion would be to have a wrapper interface OMParent that contains
> > > > > in it the child API methods ( 6 of them). Its good to have child
> > > > > navigation API within OMParent than anywhere else (currently it's in
> > > > > OMElement). Subsequently OMElementImpl class and OMDocument class if
> > > > > they implement this OMParent all the existing code will remain to be
> > > > > intact with the additional desired functionality that OMDocument can
> > > > > hold multiple entities in it.
> > > > >
> > > > > Thanks
> > > > > Jaya
> > > > >
> > > > > My idea boils down to something like
> > > > >
> > > > > //child navigation API methods will be shifted from OMElement to
> > > > > OMParent interface
> > > > > public interface OMParent {
> > > > > public void addChild(OMNode omNode);
> > > > > public Iterator getChildrenWithName(QName elementQName) throws
> > > > > OMException;
> > > > > public OMElement getFirstChildWithName(QName elementQName) throws
> > > > > OMException;
> > > > > public Iterator getChildren();
> > > > > public void setFirstChild(OMNode node);
> > > > > public OMNode getFirstChild();
> > > > > }
> > > > >
> > > > > //OMElementImpl should implement OMParent
> > > > > public class OMElementImpl extends OMNodeImpl implements
> > > OMParent,...{...}
> > > > >
> > > > > //OMDocument should implement OMParent
> > > > > public class OMDocument implements OMParent {...}
> > > > >
> > > > > //The parent datamember in OMNodeImpl will be typed as OMParent type
> > > > > public class OMNodeImpl implements OMNode {
> > > > > ...
> > > > > protected OMParent parent; // << parent should no longer be
> > > OMElementImpl
> > > > > type
> > > > > ...
> > > > > ...
> > > > > }
> > > > >
> > > > > Thank you
> > > > > Jayachandra
> > > > >
> > > > > On 6/1/05, jayachandra <ja...@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.
> > > > > >
> > > > > > Jaya
> > > > > >
> > > > > > On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Jaya
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
>
Re: [Axis2] Need for children API for OMDocument
Posted by Venkat Reddy <vr...@gmail.com>.
just saw some more issues if we go with new Interface.
The client API 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.
If we add a new method SOAPFactory.createOMParent(), then the entire
client API has to deal with OMParent objects instead of OMElement
objects while building the message, which looks weird.
- Venkat
On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> Didn't I gave my +1 for this. Ok here goes, +1 ;).
>
> -- Chinthaka
>
> > -----Original Message-----
> > From: Venkat Reddy [mailto:vreddyp@gmail.com]
> > Sent: Thursday, June 02, 2005 10:55 AM
> > To: axis-dev@ws.apache.org
> > Subject: Re: [Axis2] Need for children API for OMDocument
> >
> > Not another class, but OMElementImpl need to implement the new
> > interface and all the child API be moved from OMElement to OMParent.
> > Also note that OMNode.setParent() now receives OMPraent, instead of
> > OMElement.
> >
> > So the result is - OMDocument now implements only child navigation API
> > and avoids stuff like namaespaces and attributes. +1.
> >
> > - venkat
> >
> > On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> > > I'm ok with having an "interface" for parent, but not another class.
> > >
> > > -- Chinthaka
> > >
> > > > -----Original Message-----
> > > > From: jayachandra [mailto:jayachandra@gmail.com]
> > > > Sent: Wednesday, June 01, 2005 7:32 PM
> > > > To: axis-dev@ws.apache.org
> > > > Subject: Re: [Axis2] Need for children API for OMDocument
> > > >
> > > > While duplicating the child API into OMDocument I got stuck at
> > something.
> > > > The addChild() method of in turn tries to setParent(), and the
> > > > datamember parent is rigidly typed to be an OMElement only.
> > > > /**
> > > > * Field parent
> > > > */
> > > > protected OMElementImpl parent;
> > > >
> > > > Now that OMDocument can also be a parent other than just OMElement, my
> > > > suggestion would be to have a wrapper interface OMParent that contains
> > > > in it the child API methods ( 6 of them). Its good to have child
> > > > navigation API within OMParent than anywhere else (currently it's in
> > > > OMElement). Subsequently OMElementImpl class and OMDocument class if
> > > > they implement this OMParent all the existing code will remain to be
> > > > intact with the additional desired functionality that OMDocument can
> > > > hold multiple entities in it.
> > > >
> > > > Thanks
> > > > Jaya
> > > >
> > > > My idea boils down to something like
> > > >
> > > > //child navigation API methods will be shifted from OMElement to
> > > > OMParent interface
> > > > public interface OMParent {
> > > > public void addChild(OMNode omNode);
> > > > public Iterator getChildrenWithName(QName elementQName) throws
> > > > OMException;
> > > > public OMElement getFirstChildWithName(QName elementQName) throws
> > > > OMException;
> > > > public Iterator getChildren();
> > > > public void setFirstChild(OMNode node);
> > > > public OMNode getFirstChild();
> > > > }
> > > >
> > > > //OMElementImpl should implement OMParent
> > > > public class OMElementImpl extends OMNodeImpl implements
> > OMParent,...{...}
> > > >
> > > > //OMDocument should implement OMParent
> > > > public class OMDocument implements OMParent {...}
> > > >
> > > > //The parent datamember in OMNodeImpl will be typed as OMParent type
> > > > public class OMNodeImpl implements OMNode {
> > > > ...
> > > > protected OMParent parent; // << parent should no longer be
> > OMElementImpl
> > > > type
> > > > ...
> > > > ...
> > > > }
> > > >
> > > > Thank you
> > > > Jayachandra
> > > >
> > > > On 6/1/05, jayachandra <ja...@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.
> > > > >
> > > > > Jaya
> > > > >
> > > > > On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
> > > > >
> > > >
> > > >
> > > > --
> > > > -- Jaya
> > >
> > >
> > >
> > >
>
>
>
>
RE: [Axis2] Need for children API for OMDocument
Posted by Eran Chinthaka <ch...@opensource.lk>.
Didn't I gave my +1 for this. Ok here goes, +1 ;).
-- Chinthaka
> -----Original Message-----
> From: Venkat Reddy [mailto:vreddyp@gmail.com]
> Sent: Thursday, June 02, 2005 10:55 AM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Need for children API for OMDocument
>
> Not another class, but OMElementImpl need to implement the new
> interface and all the child API be moved from OMElement to OMParent.
> Also note that OMNode.setParent() now receives OMPraent, instead of
> OMElement.
>
> So the result is - OMDocument now implements only child navigation API
> and avoids stuff like namaespaces and attributes. +1.
>
> - venkat
>
> On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> > I'm ok with having an "interface" for parent, but not another class.
> >
> > -- Chinthaka
> >
> > > -----Original Message-----
> > > From: jayachandra [mailto:jayachandra@gmail.com]
> > > Sent: Wednesday, June 01, 2005 7:32 PM
> > > To: axis-dev@ws.apache.org
> > > Subject: Re: [Axis2] Need for children API for OMDocument
> > >
> > > While duplicating the child API into OMDocument I got stuck at
> something.
> > > The addChild() method of in turn tries to setParent(), and the
> > > datamember parent is rigidly typed to be an OMElement only.
> > > /**
> > > * Field parent
> > > */
> > > protected OMElementImpl parent;
> > >
> > > Now that OMDocument can also be a parent other than just OMElement, my
> > > suggestion would be to have a wrapper interface OMParent that contains
> > > in it the child API methods ( 6 of them). Its good to have child
> > > navigation API within OMParent than anywhere else (currently it's in
> > > OMElement). Subsequently OMElementImpl class and OMDocument class if
> > > they implement this OMParent all the existing code will remain to be
> > > intact with the additional desired functionality that OMDocument can
> > > hold multiple entities in it.
> > >
> > > Thanks
> > > Jaya
> > >
> > > My idea boils down to something like
> > >
> > > //child navigation API methods will be shifted from OMElement to
> > > OMParent interface
> > > public interface OMParent {
> > > public void addChild(OMNode omNode);
> > > public Iterator getChildrenWithName(QName elementQName) throws
> > > OMException;
> > > public OMElement getFirstChildWithName(QName elementQName) throws
> > > OMException;
> > > public Iterator getChildren();
> > > public void setFirstChild(OMNode node);
> > > public OMNode getFirstChild();
> > > }
> > >
> > > //OMElementImpl should implement OMParent
> > > public class OMElementImpl extends OMNodeImpl implements
> OMParent,...{...}
> > >
> > > //OMDocument should implement OMParent
> > > public class OMDocument implements OMParent {...}
> > >
> > > //The parent datamember in OMNodeImpl will be typed as OMParent type
> > > public class OMNodeImpl implements OMNode {
> > > ...
> > > protected OMParent parent; // << parent should no longer be
> OMElementImpl
> > > type
> > > ...
> > > ...
> > > }
> > >
> > > Thank you
> > > Jayachandra
> > >
> > > On 6/1/05, jayachandra <ja...@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.
> > > >
> > > > Jaya
> > > >
> > > > On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
> > > >
> > >
> > >
> > > --
> > > -- Jaya
> >
> >
> >
> >
Re: [Axis2] Need for children API for OMDocument
Posted by Venkat Reddy <vr...@gmail.com>.
Not another class, but OMElementImpl need to implement the new
interface and all the child API be moved from OMElement to OMParent.
Also note that OMNode.setParent() now receives OMPraent, instead of
OMElement.
So the result is - OMDocument now implements only child navigation API
and avoids stuff like namaespaces and attributes. +1.
- venkat
On 6/2/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> I'm ok with having an "interface" for parent, but not another class.
>
> -- Chinthaka
>
> > -----Original Message-----
> > From: jayachandra [mailto:jayachandra@gmail.com]
> > Sent: Wednesday, June 01, 2005 7:32 PM
> > To: axis-dev@ws.apache.org
> > Subject: Re: [Axis2] Need for children API for OMDocument
> >
> > While duplicating the child API into OMDocument I got stuck at something.
> > The addChild() method of in turn tries to setParent(), and the
> > datamember parent is rigidly typed to be an OMElement only.
> > /**
> > * Field parent
> > */
> > protected OMElementImpl parent;
> >
> > Now that OMDocument can also be a parent other than just OMElement, my
> > suggestion would be to have a wrapper interface OMParent that contains
> > in it the child API methods ( 6 of them). Its good to have child
> > navigation API within OMParent than anywhere else (currently it's in
> > OMElement). Subsequently OMElementImpl class and OMDocument class if
> > they implement this OMParent all the existing code will remain to be
> > intact with the additional desired functionality that OMDocument can
> > hold multiple entities in it.
> >
> > Thanks
> > Jaya
> >
> > My idea boils down to something like
> >
> > //child navigation API methods will be shifted from OMElement to
> > OMParent interface
> > public interface OMParent {
> > public void addChild(OMNode omNode);
> > public Iterator getChildrenWithName(QName elementQName) throws
> > OMException;
> > public OMElement getFirstChildWithName(QName elementQName) throws
> > OMException;
> > public Iterator getChildren();
> > public void setFirstChild(OMNode node);
> > public OMNode getFirstChild();
> > }
> >
> > //OMElementImpl should implement OMParent
> > public class OMElementImpl extends OMNodeImpl implements OMParent,...{...}
> >
> > //OMDocument should implement OMParent
> > public class OMDocument implements OMParent {...}
> >
> > //The parent datamember in OMNodeImpl will be typed as OMParent type
> > public class OMNodeImpl implements OMNode {
> > ...
> > protected OMParent parent; // << parent should no longer be OMElementImpl
> > type
> > ...
> > ...
> > }
> >
> > Thank you
> > Jayachandra
> >
> > On 6/1/05, jayachandra <ja...@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.
> > >
> > > Jaya
> > >
> > > On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
> > >
> >
> >
> > --
> > -- Jaya
>
>
>
>
Re: [Axis2] Need for children API for OMDocument
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
jayachandra wrote:
>While duplicating the child API into OMDocument I got stuck at something.
>The addChild() method of in turn tries to setParent(), and the
>datamember parent is rigidly typed to be an OMElement only.
> /**
> * Field parent
> */
> protected OMElementImpl parent;
>
>Now that OMDocument can also be a parent other than just OMElement, my
>suggestion would be to have a wrapper interface OMParent that contains
>in it the child API methods ( 6 of them). Its good to have child
>navigation API within OMParent than anywhere else (currently it's in
>OMElement). Subsequently OMElementImpl class and OMDocument class if
>they implement this OMParent all the existing code will remain to be
>intact with the additional desired functionality that OMDocument can
>hold multiple entities in it.
>
>Thanks
>Jaya
>
>My idea boils down to something like
>
>
i am not sure if getChildrenWithName() is needed in OMDocument but
otherwise i think it is good idea to have common "container" abstraction
for both OMDocument and OMElement.
alek
>//child navigation API methods will be shifted from OMElement to
>OMParent interface
>public interface OMParent {
> public void addChild(OMNode omNode);
> public Iterator getChildrenWithName(QName elementQName) throws OMException;
> public OMElement getFirstChildWithName(QName elementQName) throws OMException;
> public Iterator getChildren();
> public void setFirstChild(OMNode node);
> public OMNode getFirstChild();
>}
>
>//OMElementImpl should implement OMParent
>public class OMElementImpl extends OMNodeImpl implements OMParent,...{...}
>
>//OMDocument should implement OMParent
>public class OMDocument implements OMParent {...}
>
>//The parent datamember in OMNodeImpl will be typed as OMParent type
>public class OMNodeImpl implements OMNode {
>...
>protected OMParent parent; // << parent should no longer be OMElementImpl type
>...
>...
>}
>
>Thank you
>Jayachandra
>
>On 6/1/05, jayachandra <ja...@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.
>>
>>Jaya
>>
>>On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2] Need for children API for OMDocument
Posted by Eran Chinthaka <ch...@opensource.lk>.
I'm ok with having an "interface" for parent, but not another class.
-- Chinthaka
> -----Original Message-----
> From: jayachandra [mailto:jayachandra@gmail.com]
> Sent: Wednesday, June 01, 2005 7:32 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Need for children API for OMDocument
>
> While duplicating the child API into OMDocument I got stuck at something.
> The addChild() method of in turn tries to setParent(), and the
> datamember parent is rigidly typed to be an OMElement only.
> /**
> * Field parent
> */
> protected OMElementImpl parent;
>
> Now that OMDocument can also be a parent other than just OMElement, my
> suggestion would be to have a wrapper interface OMParent that contains
> in it the child API methods ( 6 of them). Its good to have child
> navigation API within OMParent than anywhere else (currently it's in
> OMElement). Subsequently OMElementImpl class and OMDocument class if
> they implement this OMParent all the existing code will remain to be
> intact with the additional desired functionality that OMDocument can
> hold multiple entities in it.
>
> Thanks
> Jaya
>
> My idea boils down to something like
>
> //child navigation API methods will be shifted from OMElement to
> OMParent interface
> public interface OMParent {
> public void addChild(OMNode omNode);
> public Iterator getChildrenWithName(QName elementQName) throws
> OMException;
> public OMElement getFirstChildWithName(QName elementQName) throws
> OMException;
> public Iterator getChildren();
> public void setFirstChild(OMNode node);
> public OMNode getFirstChild();
> }
>
> //OMElementImpl should implement OMParent
> public class OMElementImpl extends OMNodeImpl implements OMParent,...{...}
>
> //OMDocument should implement OMParent
> public class OMDocument implements OMParent {...}
>
> //The parent datamember in OMNodeImpl will be typed as OMParent type
> public class OMNodeImpl implements OMNode {
> ...
> protected OMParent parent; // << parent should no longer be OMElementImpl
> type
> ...
> ...
> }
>
> Thank you
> Jayachandra
>
> On 6/1/05, jayachandra <ja...@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.
> >
> > Jaya
> >
> > On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
> >
>
>
> --
> -- Jaya
Re: [Axis2] Need for children API for OMDocument
Posted by jayachandra <ja...@gmail.com>.
While duplicating the child API into OMDocument I got stuck at something.
The addChild() method of in turn tries to setParent(), and the
datamember parent is rigidly typed to be an OMElement only.
/**
* Field parent
*/
protected OMElementImpl parent;
Now that OMDocument can also be a parent other than just OMElement, my
suggestion would be to have a wrapper interface OMParent that contains
in it the child API methods ( 6 of them). Its good to have child
navigation API within OMParent than anywhere else (currently it's in
OMElement). Subsequently OMElementImpl class and OMDocument class if
they implement this OMParent all the existing code will remain to be
intact with the additional desired functionality that OMDocument can
hold multiple entities in it.
Thanks
Jaya
My idea boils down to something like
//child navigation API methods will be shifted from OMElement to
OMParent interface
public interface OMParent {
public void addChild(OMNode omNode);
public Iterator getChildrenWithName(QName elementQName) throws OMException;
public OMElement getFirstChildWithName(QName elementQName) throws OMException;
public Iterator getChildren();
public void setFirstChild(OMNode node);
public OMNode getFirstChild();
}
//OMElementImpl should implement OMParent
public class OMElementImpl extends OMNodeImpl implements OMParent,...{...}
//OMDocument should implement OMParent
public class OMDocument implements OMParent {...}
//The parent datamember in OMNodeImpl will be typed as OMParent type
public class OMNodeImpl implements OMNode {
...
protected OMParent parent; // << parent should no longer be OMElementImpl type
...
...
}
Thank you
Jayachandra
On 6/1/05, jayachandra <ja...@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.
>
> Jaya
>
> On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
>
--
-- Jaya
Re: [Axis2] Need for children API for OMDocument
Posted by Venkat Reddy <vr...@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 <ja...@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.
>
> Jaya
>
> On 6/1/05, Aleksander Slominski <as...@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 <ja...@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
>
RE: [Axis2] Need for children API for OMDocument
Posted by Eran Chinthaka <ch...@opensource.lk>.
+1
> -----Original Message-----
> From: jayachandra [mailto:jayachandra@gmail.com]
> Sent: Wednesday, June 01, 2005 1:30 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Need for children API for OMDocument
>
> 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 <as...@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 <ja...@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
Re: [Axis2] Need for children API for OMDocument
Posted by jayachandra <ja...@gmail.com>.
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 <as...@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 <ja...@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
Re: [Axis2] Need for children API for OMDocument
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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 <ja...@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