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/04/12 08:58:30 UTC
[Axis2] OMNodeImpl notes
Hi devs!
Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
This appears problematic. Because for document level comments (i mean,
comments that are present outside the root element in the XML
document) parent becomes OMDocument rather than OMElement. So better
have the 'parent' data member as Object. And accordingly the return
type of getParent will be Object. I hope this change will not break
any existing code, will it???
Jaya
--
-- Jaya
Re: [Axis2] OMNodeImpl notes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
jayachandra wrote:
>Hi devs!
>
>Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
>This appears problematic. Because for document level comments (i mean,
>comments that are present outside the root element in the XML
>document) parent becomes OMDocument rather than OMElement. So better
>have the 'parent' data member as Object. And accordingly the return
>type of getParent will be Object. I hope this change will not break
>any existing code, will it???
>
>
hi Jaya,
IMHO Object is a bit too broad and will be hard to understand when
somebody see Object getParent() what are legal values for parent -
instead you could create a common base interface for OMElement and
OMDocument (OMContainer?) and use it as result of getParent - i did this
in XPP3/XB1 and it works well for the case you mention and similiar
situation suchas top level element that is child of document (so called
document element).
you can get more sophisticated about it and also model containment
relations:
/**
* Common abstraction shared between XmlElement, XmlDocument and XmlDoctype
* to represent XML Infoset item that can contain other Infoset items
* This is useful so getParent() operation will return this instead of
Object ...
*/
public interface XmlContainer {
}
/**
* Common abstraction to represent XML infoset item that are contained
in other infoet items
* This is useful so parent can be updated on contained items when
container is cloned ...
*/
public interface XmlContained{
public XmlContainer getParent();
public void setParent(XmlContainer el);
}
public interface XmlElement extends XmlContainer, XmlContained, Cloneable {
...
}
public interface XmlDocument extends XmlContainer, Cloneable {
...
}
HTH.
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2] OMNodeImpl notes
Posted by Eran Chinthaka <ch...@opensource.lk>.
Wow !! seems like I've missed lot of action. :). Sorry guys, I couldn't
access my mails properly since 8th, due to some mail server problem.
Anyway, Venkat has answered me, without me saying anything ;).
Coming back to the problem. Yes, I agree with you all that there are some
problems in OM, which are not that serious, due to tweaking, as Ajith
mentioned.
These days we are "cleaning" OM. So give us sometime to come up with a good
OM.
Problems I see in the current impl
1. Current impl was not done, thinking of supporting the full infoset. We
have tried to optimize for SOAP messages. So things like Document has been
removed.
2. When supporting SwA, there can be attachments which are not clearly
linked to the SOAP message. So we need a mechanism to hold those attachments
outside the SOAP envelope. One option is to have these in the Document.
3. The builder hierarchy is not good. StAXOMBuilder, MTOMBuilder and
StAXSOAPModelBuilder should be handled better than now.
4. Serialising code some issues. So worth reconsidering to re-write that.
Those are some of the problems we have. Let us come up with a proposal soon,
hopefully within this week. But unfortunately this *MAY* affect some of the
implementations on top of OM. So bear with us a bit.
Thanks and Regards,
Eran Chinthaka
> -----Original Message-----
> From: Venkat Reddy [mailto:vreddyp@gmail.com]
> Sent: Thursday, April 21, 2005 9:00 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] OMNodeImpl notes
>
> >
> http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMTextImpl.htm
> l
>
> btw, it looks like OMTextImpl already has setFirstChild and
> getFirstChild methods!! may be the remains of last refactoring?
>
> - venkat
>
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
> http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMTextImpl.html
btw, it looks like OMTextImpl already has setFirstChild and
getFirstChild methods!! may be the remains of last refactoring?
- venkat
Re: [Axis2] OMNodeImpl notes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Venkat Reddy wrote:
>On 4/19/05, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
>
>>Venkat Reddy wrote:
>>
>>
>>
>>why not call it node OMChildrenManagement interface and have OMDocument
>>and OMElement implement. no need for OMText to implement it ...
>>
>>
>
>It works. Except that OMNode is still not well defined for its role
>and the API for children, sibling and parent are scattered around all
>the three interfaces.
>
>
OMChildrenManagement should just manage children (and siblings as well ...)
an additional interface (for example OMContained { getParent() } ) could deal just with parental relations (attribute contained in element etc)
>>>Well, this might make it look more like DOM, but nothing wrong in
>>>taking the good things from it :-)
>>>
>>>
>>IMHO Node is not good thing - it was a dual interface for languages that
>>did not support OO so they could use one class to work with any type of
>>node. the preferred interface for Java should be proper hierarchy of
>>classes/interfaces and asking programmer to figure out which method are
>>usable in given context so they do not throw OMException or return
>>special error value is not making of easy to use API ...
>>
>>
>
>I dont think Node is such bad thing to have as the root level
>abstraction of a tree API. Also I feel an interface is designed for
>more commonly used API by its derivatives and impls, but not for the
>least common features. The balance is required to avoid duplication of
>code and modularization of related API into same place.
>
>
let me just state this for record - requiring OMText to implement OMNode
is confusing for non-DOM trained Java programmers (and just a bit less
confusing for DOM-trained) - moreover if String could be used it would
make for much smaller memory footprint (and simpler code) when DOM is
not needed as it would be no need for wrapper class (OMTextImpl) that
carries besides string value set of toher fields such as |done
<http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMNodeImpl.html#done>,
nextSibling
<http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMNodeImpl.html#nextSibling>,
nodeType
<http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMNodeImpl.html#nodeType>,
parent
<http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMNodeImpl.html#parent>,
previousSibling
<http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMNodeImpl.html#previousSibling>
(and people wonder why DOM is memory intensive ...) - based on:
http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMTextImpl.html|
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
On 4/19/05, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Venkat Reddy wrote:
>
> >Currently OMElement is doing most of tree manipulation and element
> >information management (attributes, namespace, tagname, children etc).
> >OMNode is also doing a bit of both through the api for sibling,
> >parent, detach, value, type, serialize etc.
> >
> >I thought, may be we can separate the roles cleanly for OMNode to
> >manipulate the tree and OMElement to take care of element specific
> >data and specialized tree api (getchildrenWithName etc).
> >
> >This will mean OMText also will also inherit the tree API to add
> >children, but we can restrict it inside OMText class, by throwing
> >OMException.
> >
> >
> that is *not* very intuitive and strange hack for Java programmers ...
Hmm, i would say that not having children is a requirement for OMText,
and not for OMNode.
On the other hand, child API is generic enough to go into OMNode than
be a specialization of OMElement for two reasons - The usecase of
OMDocument indicates that OMNode should support child API, and the all
those methods that i mentioned mostly operate on OMNode objects.
>
> >I'm not sure about increase in memory foot print, as mentioned by
> >Alek.
> >
> devil is in details - it is tempting to have base OMNode implementation
> and have OMText extend it ...
Temptations result in associated costs ;-) OMText need not extend
something which is too heavy for it. It should just implement OMNode
to the extent it needs.
>
> > The OMNode interface will be added with only a few new methods
> >but not any new data. The OMText class also need not implement any
> >additional data.
> >
> >The benefit of this change would be that - OMNode will get a clear
> >role and can be optimized independently. OMElement can focus on the
> >XML element specific activities.
> >
> >Actually all the child API methods in OMElement are dealing with only
> >OMNode, and so they seem to belong to OMNode.
> >
> > public void addChild(OMNode omNode);
> > public Iterator getChildren();
> > public void setFirstChild(OMNode node);
> > public OMNode getFirstChild();
> >
> >
> why not call it node OMChildrenManagement interface and have OMDocument
> and OMElement implement. no need for OMText to implement it ...
It works. Except that OMNode is still not well defined for its role
and the API for children, sibling and parent are scattered around all
the three interfaces.
>
> >Well, this might make it look more like DOM, but nothing wrong in
> >taking the good things from it :-)
> >
> >
> IMHO Node is not good thing - it was a dual interface for languages that
> did not support OO so they could use one class to work with any type of
> node. the preferred interface for Java should be proper hierarchy of
> classes/interfaces and asking programmer to figure out which method are
> usable in given context so they do not throw OMException or return
> special error value is not making of easy to use API ...
I dont think Node is such bad thing to have as the root level
abstraction of a tree API. Also I feel an interface is designed for
more commonly used API by its derivatives and impls, but not for the
least common features. The balance is required to avoid duplication of
code and modularization of related API into same place.
- venkat
>
> alek
>
Re: [Axis2] OMNodeImpl notes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Venkat Reddy wrote:
>Oh, boy! this is not to suggest huge changes, as jaya said :-) You
>guys already did enourmous work in designing this stuff. I'm just
>trying to see if some api changes would make more sense.
>
>Currently OMElement is doing most of tree manipulation and element
>information management (attributes, namespace, tagname, children etc).
>OMNode is also doing a bit of both through the api for sibling,
>parent, detach, value, type, serialize etc.
>
>I thought, may be we can separate the roles cleanly for OMNode to
>manipulate the tree and OMElement to take care of element specific
>data and specialized tree api (getchildrenWithName etc).
>
>This will mean OMText also will also inherit the tree API to add
>children, but we can restrict it inside OMText class, by throwing
>OMException.
>
>
that is *not* very intuitive and strange hack for Java programmers ...
>I'm not sure about increase in memory foot print, as mentioned by
>Alek.
>
devil is in details - it is tempting to have base OMNode implementation
and have OMText extend it ...
> The OMNode interface will be added with only a few new methods
>but not any new data. The OMText class also need not implement any
>additional data.
>
>The benefit of this change would be that - OMNode will get a clear
>role and can be optimized independently. OMElement can focus on the
>XML element specific activities.
>
>Actually all the child API methods in OMElement are dealing with only
>OMNode, and so they seem to belong to OMNode.
>
> public void addChild(OMNode omNode);
> public Iterator getChildren();
> public void setFirstChild(OMNode node);
> public OMNode getFirstChild();
>
>
why not call it node OMChildrenManagement interface and have OMDocument
and OMElement implement. no need for OMText to implement it ...
>Well, this might make it look more like DOM, but nothing wrong in
>taking the good things from it :-)
>
>
IMHO Node is not good thing - it was a dual interface for languages that
did not support OO so they could use one class to work with any type of
node. the preferred interface for Java should be proper hierarchy of
classes/interfaces and asking programmer to figure out which method are
usable in given context so they do not throw OMException or return
special error value is not making of easy to use API ...
alek
>
>
>On 4/19/05, Ajith Ranabahu <aj...@gmail.com> wrote:
>
>
>>Hi,
>>Yes I have to admit that "time to time tweaking" has corrupted OM to a
>>certain extent. For starters I am not happy about the serilizing code and
>>planning to rewrite it (without putting you guys in trouble ofcourse :)) May
>>be I can team up with Chinthaka and go through the OM hierarchies to find
>>inconsistancies and fix them. You input is also much welcome.
>>BTW I also agree that this is the best time to tackle this problem. If we go
>>on further it will be harder to modify.
>>
>>On 4/19/05, jayachandra < jayachandra@gmail.com> wrote:
>>
>>
>>>As seen by Venkat, I too feel there is a serious lack of role
>>>definitions and proper design when it comes to OM code (viz. OMNode
>>>not doing the supposed tree manipulation stuff, OMElement deviating
>>>from its semantics to do tree manipulation stuff and other such
>>>anamolies). May be a detailed mail (by Venkat?) explaining all such
>>>things and with due emphasis on good design practices can help us
>>>refactor the code fully. We better do that refactoring as early as
>>>possible rather regret in the end after the code base grows gigantic
>>>beyond refactoring.
>>>
>>>Awaiting a detailed mail from Venkat!
>>>
>>>Bye
>>>Jaya
>>>
>>>
>>>
>>>
>>>
>>--
>>Ajith Ranabahu
>>
>>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
Oh, boy! this is not to suggest huge changes, as jaya said :-) You
guys already did enourmous work in designing this stuff. I'm just
trying to see if some api changes would make more sense.
Currently OMElement is doing most of tree manipulation and element
information management (attributes, namespace, tagname, children etc).
OMNode is also doing a bit of both through the api for sibling,
parent, detach, value, type, serialize etc.
I thought, may be we can separate the roles cleanly for OMNode to
manipulate the tree and OMElement to take care of element specific
data and specialized tree api (getchildrenWithName etc).
This will mean OMText also will also inherit the tree API to add
children, but we can restrict it inside OMText class, by throwing
OMException.
I'm not sure about increase in memory foot print, as mentioned by
Alek. The OMNode interface will be added with only a few new methods
but not any new data. The OMText class also need not implement any
additional data.
The benefit of this change would be that - OMNode will get a clear
role and can be optimized independently. OMElement can focus on the
XML element specific activities.
Actually all the child API methods in OMElement are dealing with only
OMNode, and so they seem to belong to OMNode.
public void addChild(OMNode omNode);
public Iterator getChildren();
public void setFirstChild(OMNode node);
public OMNode getFirstChild();
Well, this might make it look more like DOM, but nothing wrong in
taking the good things from it :-)
- venkat
On 4/19/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi,
> Yes I have to admit that "time to time tweaking" has corrupted OM to a
> certain extent. For starters I am not happy about the serilizing code and
> planning to rewrite it (without putting you guys in trouble ofcourse :)) May
> be I can team up with Chinthaka and go through the OM hierarchies to find
> inconsistancies and fix them. You input is also much welcome.
> BTW I also agree that this is the best time to tackle this problem. If we go
> on further it will be harder to modify.
>
> On 4/19/05, jayachandra < jayachandra@gmail.com> wrote:
> > As seen by Venkat, I too feel there is a serious lack of role
> > definitions and proper design when it comes to OM code (viz. OMNode
> > not doing the supposed tree manipulation stuff, OMElement deviating
> > from its semantics to do tree manipulation stuff and other such
> > anamolies). May be a detailed mail (by Venkat?) explaining all such
> > things and with due emphasis on good design practices can help us
> > refactor the code fully. We better do that refactoring as early as
> > possible rather regret in the end after the code base grows gigantic
> > beyond refactoring.
> >
> > Awaiting a detailed mail from Venkat!
> >
> > Bye
> > Jaya
> >
> >
> >
>
>
> --
> Ajith Ranabahu
Re: [Axis2] OMNodeImpl notes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
Yes I have to admit that "time to time tweaking" has corrupted OM to a
certain extent. For starters I am not happy about the serilizing code and
planning to rewrite it (without putting you guys in trouble ofcourse :)) May
be I can team up with Chinthaka and go through the OM hierarchies to find
inconsistancies and fix them. You input is also much welcome.
BTW I also agree that this is the best time to tackle this problem. If we go
on further it will be harder to modify.
On 4/19/05, jayachandra <ja...@gmail.com> wrote:
>
> As seen by Venkat, I too feel there is a serious lack of role
> definitions and proper design when it comes to OM code (viz. OMNode
> not doing the supposed tree manipulation stuff, OMElement deviating
> from its semantics to do tree manipulation stuff and other such
> anamolies). May be a detailed mail (by Venkat?) explaining all such
> things and with due emphasis on good design practices can help us
> refactor the code fully. We better do that refactoring as early as
> possible rather regret in the end after the code base grows gigantic
> beyond refactoring.
>
> Awaiting a detailed mail from Venkat!
>
> Bye
> Jaya
>
>
>
--
Ajith Ranabahu
Re: [Axis2] OMNodeImpl notes
Posted by jayachandra <ja...@gmail.com>.
As seen by Venkat, I too feel there is a serious lack of role
definitions and proper design when it comes to OM code (viz. OMNode
not doing the supposed tree manipulation stuff, OMElement deviating
from its semantics to do tree manipulation stuff and other such
anamolies). May be a detailed mail (by Venkat?) explaining all such
things and with due emphasis on good design practices can help us
refactor the code fully. We better do that refactoring as early as
possible rather regret in the end after the code base grows gigantic
beyond refactoring.
Awaiting a detailed mail from Venkat!
Bye
Jaya
On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
> On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> > Hi,
> > I guess this is another facet of the SOAP vs pure XML problem :). The reason
> > why we are not so keen on having an OMDocument is that it is just redundant
> > when it comes to SOAP message processing (except for a PI which we are happy
> > to skip:)).
> > IMHO you will probably need to reinstate the OMDocument if full infoset
> > support is needed!
> >
>
> Eran,
>
> 1. Given that we need to implement full infoset support, do we still
> think OMDocument and PIs are such bad things? :)
>
> 2. As i mentioned, the StaxOMBuilder is already instantiating
> OMDocument on the START_DOCUMENT event. I hope you meant the same by
> "reinstating OMDocument"?
>
> 3. What do you think about moving child node API from OMElement to
> OMNode and OMDocument implementing OMNode?
>
> - venkat
>
> >
> > On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
> > > Before i talk about the problem, Eran, i see that we are still
> > > creating the OMDocument and setting the first ELEMENT_NODE as its
> > > rootElement. - isn't it?
> > >
> > > The problem as i understood:
> > >
> > > There are stuff other than root element (envelop) that need go as
> > > children into the OMDocument object. Currently this is not possible
> > > because OMDocument isn't designed to contain anything other than
> > > rootElement.
> > >
> > > Possible solutions:
> > >
> > > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > > from OMElement to OMNode. I think this is preferable becaus the
> > > addChild, getChild sort of methods seem more natural to OMNode than
> > > OMElement. OMElement can have addChildElement etc, if needed.
> > >
> > > 2. Make OMDocument to extend OMElement, but i think this is an
> > > overkill, because the Document object isn't really an XML element.
> > >
> > > I didn't understand why we need Object or OMContainer as parent. May
> > > be i'm missing something.
> > >
> > > - venkat
> > >
> > >
> > > On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
> > > > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > > > > Hi devs!
> > > > >
> > > > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > > > This appears problematic. Because for document level comments (i mean,
> > > > > comments that are present outside the root element in the XML
> > > > > document) parent becomes OMDocument rather than OMElement. So better
> > > > > have the 'parent' data member as Object. And accordingly the return
> > > > > type of getParent will be Object. I hope this change will not break
> > > > > any existing code, will it???
> > > >
> > > > This will not break any of the code. But this will add some bad
> > > > things, IMHO, to code. For example, anything can be a parent of any
> > > > node, even a Text node.
> > > > That was the main reason why, we purposely made parent to an OMElement.
> > > >
> > > > I understand your concern, but ............
> > > >
> > > > And there is another question coming from me, is it necessary to
> > > > provice the ability to add comments to the Document which is even out
> > > > of the document element ??
> > > >
> > > > Making this available is of not that useful, but will add some weird
> > > > look to the code.
> > > >
> > > > We earlier had the concept of OMDocument, but later removed it.
> > > >
> > > > For your all information : These days all the Sri Lankan people have
> > > > gone home to celebrate our Sinhalese new year festival. So, there may
> > > > be (including me), a deley in replying to the mails. :(
> > > >
> > > > Regards,
> > > > Chinthaka
> > > >
> > > > >
> > > > > Jaya
> > > > > --
> > > > > -- Jaya
> > > > >
> > > >
> > > > --
> > > >
> > --------------------------------------------------------
> > > > Eran Chinthaka
> > > >
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
>
--
-- Jaya
Re: [Axis2] OMNodeImpl notes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Venkat,
1.Well, OMDocument is not a bad thing. ultimately we need to expose it to
the user. The important thing is that this OMDocument should not be visible
to the user in the SOAP API. So as far as the SOAP API's are intact I have
no objection in putting up the OMDocument.
2. Not really. Even though the OMDocument is there, it is not returned to
the user in any case. The builder returns the document element , not the
document object. What I mean by saying re-instating is showing up the
OMDocument in the API.
3. Hmmmm. That I have to think about. I am not sure what kind of impact it
will have. However for pure accuracy, extending OMnode to make the OMDocment
is the correct thing.
On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
>
> Sorry, i meant to address Ajith, not Eran - was a typo :-)
>
> On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
> > On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> > > Hi,
> > > I guess this is another facet of the SOAP vs pure XML problem :). The
> reason
> > > why we are not so keen on having an OMDocument is that it is just
> redundant
> > > when it comes to SOAP message processing (except for a PI which we are
> happy
> > > to skip:)).
> > > IMHO you will probably need to reinstate the OMDocument if full
> infoset
> > > support is needed!
> > >
> >
> > Eran,
> >
> > 1. Given that we need to implement full infoset support, do we still
> > think OMDocument and PIs are such bad things? :)
> >
> > 2. As i mentioned, the StaxOMBuilder is already instantiating
> > OMDocument on the START_DOCUMENT event. I hope you meant the same by
> > "reinstating OMDocument"?
> >
> > 3. What do you think about moving child node API from OMElement to
> > OMNode and OMDocument implementing OMNode?
> >
> > - venkat
> >
> > >
> > > On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
> > > > Before i talk about the problem, Eran, i see that we are still
> > > > creating the OMDocument and setting the first ELEMENT_NODE as its
> > > > rootElement. - isn't it?
> > > >
> > > > The problem as i understood:
> > > >
> > > > There are stuff other than root element (envelop) that need go as
> > > > children into the OMDocument object. Currently this is not possible
> > > > because OMDocument isn't designed to contain anything other than
> > > > rootElement.
> > > >
> > > > Possible solutions:
> > > >
> > > > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > > > from OMElement to OMNode. I think this is preferable becaus the
> > > > addChild, getChild sort of methods seem more natural to OMNode than
> > > > OMElement. OMElement can have addChildElement etc, if needed.
> > > >
> > > > 2. Make OMDocument to extend OMElement, but i think this is an
> > > > overkill, because the Document object isn't really an XML element.
> > > >
> > > > I didn't understand why we need Object or OMContainer as parent. May
> > > > be i'm missing something.
> > > >
> > > > - venkat
> > > >
> > > >
> > > > On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
> > > > > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com>
> wrote:
> > > > > > Hi devs!
> > > > > >
> > > > > > Currently OMNodeImpl has the data memeber 'parent' of type
> OMElement.
> > > > > > This appears problematic. Because for document level comments (i
> mean,
> > > > > > comments that are present outside the root element in the XML
> > > > > > document) parent becomes OMDocument rather than OMElement. So
> better
> > > > > > have the 'parent' data member as Object. And accordingly the
> return
> > > > > > type of getParent will be Object. I hope this change will not
> break
> > > > > > any existing code, will it???
> > > > >
> > > > > This will not break any of the code. But this will add some bad
> > > > > things, IMHO, to code. For example, anything can be a parent of
> any
> > > > > node, even a Text node.
> > > > > That was the main reason why, we purposely made parent to an
> OMElement.
> > > > >
> > > > > I understand your concern, but ............
> > > > >
> > > > > And there is another question coming from me, is it necessary to
> > > > > provice the ability to add comments to the Document which is even
> out
> > > > > of the document element ??
> > > > >
> > > > > Making this available is of not that useful, but will add some
> weird
> > > > > look to the code.
> > > > >
> > > > > We earlier had the concept of OMDocument, but later removed it.
> > > > >
> > > > > For your all information : These days all the Sri Lankan people
> have
> > > > > gone home to celebrate our Sinhalese new year festival. So, there
> may
> > > > > be (including me), a deley in replying to the mails. :(
> > > > >
> > > > > Regards,
> > > > > Chinthaka
> > > > >
> > > > > >
> > > > > > Jaya
> > > > > > --
> > > > > > -- Jaya
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > --------------------------------------------------------
> > > > > Eran Chinthaka
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Ajith Ranabahu
> >
>
--
Ajith Ranabahu
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
Sorry, i meant to address Ajith, not Eran - was a typo :-)
On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
> On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> > Hi,
> > I guess this is another facet of the SOAP vs pure XML problem :). The reason
> > why we are not so keen on having an OMDocument is that it is just redundant
> > when it comes to SOAP message processing (except for a PI which we are happy
> > to skip:)).
> > IMHO you will probably need to reinstate the OMDocument if full infoset
> > support is needed!
> >
>
> Eran,
>
> 1. Given that we need to implement full infoset support, do we still
> think OMDocument and PIs are such bad things? :)
>
> 2. As i mentioned, the StaxOMBuilder is already instantiating
> OMDocument on the START_DOCUMENT event. I hope you meant the same by
> "reinstating OMDocument"?
>
> 3. What do you think about moving child node API from OMElement to
> OMNode and OMDocument implementing OMNode?
>
> - venkat
>
> >
> > On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
> > > Before i talk about the problem, Eran, i see that we are still
> > > creating the OMDocument and setting the first ELEMENT_NODE as its
> > > rootElement. - isn't it?
> > >
> > > The problem as i understood:
> > >
> > > There are stuff other than root element (envelop) that need go as
> > > children into the OMDocument object. Currently this is not possible
> > > because OMDocument isn't designed to contain anything other than
> > > rootElement.
> > >
> > > Possible solutions:
> > >
> > > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > > from OMElement to OMNode. I think this is preferable becaus the
> > > addChild, getChild sort of methods seem more natural to OMNode than
> > > OMElement. OMElement can have addChildElement etc, if needed.
> > >
> > > 2. Make OMDocument to extend OMElement, but i think this is an
> > > overkill, because the Document object isn't really an XML element.
> > >
> > > I didn't understand why we need Object or OMContainer as parent. May
> > > be i'm missing something.
> > >
> > > - venkat
> > >
> > >
> > > On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
> > > > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > > > > Hi devs!
> > > > >
> > > > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > > > This appears problematic. Because for document level comments (i mean,
> > > > > comments that are present outside the root element in the XML
> > > > > document) parent becomes OMDocument rather than OMElement. So better
> > > > > have the 'parent' data member as Object. And accordingly the return
> > > > > type of getParent will be Object. I hope this change will not break
> > > > > any existing code, will it???
> > > >
> > > > This will not break any of the code. But this will add some bad
> > > > things, IMHO, to code. For example, anything can be a parent of any
> > > > node, even a Text node.
> > > > That was the main reason why, we purposely made parent to an OMElement.
> > > >
> > > > I understand your concern, but ............
> > > >
> > > > And there is another question coming from me, is it necessary to
> > > > provice the ability to add comments to the Document which is even out
> > > > of the document element ??
> > > >
> > > > Making this available is of not that useful, but will add some weird
> > > > look to the code.
> > > >
> > > > We earlier had the concept of OMDocument, but later removed it.
> > > >
> > > > For your all information : These days all the Sri Lankan people have
> > > > gone home to celebrate our Sinhalese new year festival. So, there may
> > > > be (including me), a deley in replying to the mails. :(
> > > >
> > > > Regards,
> > > > Chinthaka
> > > >
> > > > >
> > > > > Jaya
> > > > > --
> > > > > -- Jaya
> > > > >
> > > >
> > > > --
> > > >
> > --------------------------------------------------------
> > > > Eran Chinthaka
> > > >
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
>
Re: [Axis2] OMNodeImpl notes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
jayachandra wrote:
>Seeing the code I find that OMNode is being seen as the minute
>granularity object that can be found in an XML document. And adding
>child node APIs into OMNode would throw endless recursion of things
>like OMText kind of basic node can also claim to have children. This I
>feel is undesirable. So better to have child node APIs in OMElement
>only.
>
>
that will also help to keep memory footprint lower than DOM impls ...
alek
>On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
>
>
>>On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
>>
>>
>>>Hi,
>>>I guess this is another facet of the SOAP vs pure XML problem :). The reason
>>>why we are not so keen on having an OMDocument is that it is just redundant
>>>when it comes to SOAP message processing (except for a PI which we are happy
>>>to skip:)).
>>>IMHO you will probably need to reinstate the OMDocument if full infoset
>>>support is needed!
>>>
>>>
>>>
>>Eran,
>>
>>1. Given that we need to implement full infoset support, do we still
>>think OMDocument and PIs are such bad things? :)
>>
>>2. As i mentioned, the StaxOMBuilder is already instantiating
>>OMDocument on the START_DOCUMENT event. I hope you meant the same by
>>"reinstating OMDocument"?
>>
>>3. What do you think about moving child node API from OMElement to
>>OMNode and OMDocument implementing OMNode?
>>
>>- venkat
>>
>>
>>
>>>On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
>>>
>>>
>>>>Before i talk about the problem, Eran, i see that we are still
>>>>creating the OMDocument and setting the first ELEMENT_NODE as its
>>>>rootElement. - isn't it?
>>>>
>>>>The problem as i understood:
>>>>
>>>>There are stuff other than root element (envelop) that need go as
>>>>children into the OMDocument object. Currently this is not possible
>>>>because OMDocument isn't designed to contain anything other than
>>>>rootElement.
>>>>
>>>>Possible solutions:
>>>>
>>>>1. Make OMDocument to extend OMNode, and move the addChild* methods
>>>>from OMElement to OMNode. I think this is preferable becaus the
>>>>addChild, getChild sort of methods seem more natural to OMNode than
>>>>OMElement. OMElement can have addChildElement etc, if needed.
>>>>
>>>>2. Make OMDocument to extend OMElement, but i think this is an
>>>>overkill, because the Document object isn't really an XML element.
>>>>
>>>>I didn't understand why we need Object or OMContainer as parent. May
>>>>be i'm missing something.
>>>>
>>>>- venkat
>>>>
>>>>
>>>>On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
>>>>
>>>>
>>>>>On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>Hi devs!
>>>>>>
>>>>>>Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
>>>>>>This appears problematic. Because for document level comments (i mean,
>>>>>>comments that are present outside the root element in the XML
>>>>>>document) parent becomes OMDocument rather than OMElement. So better
>>>>>>have the 'parent' data member as Object. And accordingly the return
>>>>>>type of getParent will be Object. I hope this change will not break
>>>>>>any existing code, will it???
>>>>>>
>>>>>>
>>>>>This will not break any of the code. But this will add some bad
>>>>>things, IMHO, to code. For example, anything can be a parent of any
>>>>>node, even a Text node.
>>>>>That was the main reason why, we purposely made parent to an OMElement.
>>>>>
>>>>>I understand your concern, but ............
>>>>>
>>>>>And there is another question coming from me, is it necessary to
>>>>>provice the ability to add comments to the Document which is even out
>>>>>of the document element ??
>>>>>
>>>>>Making this available is of not that useful, but will add some weird
>>>>>look to the code.
>>>>>
>>>>>We earlier had the concept of OMDocument, but later removed it.
>>>>>
>>>>>For your all information : These days all the Sri Lankan people have
>>>>>gone home to celebrate our Sinhalese new year festival. So, there may
>>>>>be (including me), a deley in replying to the mails. :(
>>>>>
>>>>>Regards,
>>>>>Chinthaka
>>>>>
>>>>>
>>>>>
>>>>>>Jaya
>>>>>>--
>>>>>>-- Jaya
>>>>>>
>>>>>>
>>>>>>
>>>>>--
>>>>>
>>>>>
>>>>>
>>>--------------------------------------------------------
>>>
>>>
>>>>>Eran Chinthaka
>>>>>
>>>>>
>>>>>
>>>
>>>--
>>>Ajith Ranabahu
>>>
>>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] OMNodeImpl notes
Posted by jayachandra <ja...@gmail.com>.
Seeing the code I find that OMNode is being seen as the minute
granularity object that can be found in an XML document. And adding
child node APIs into OMNode would throw endless recursion of things
like OMText kind of basic node can also claim to have children. This I
feel is undesirable. So better to have child node APIs in OMElement
only.
Thank you,
Jayachandra
On 4/18/05, Venkat Reddy <vr...@gmail.com> wrote:
> On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> > Hi,
> > I guess this is another facet of the SOAP vs pure XML problem :). The reason
> > why we are not so keen on having an OMDocument is that it is just redundant
> > when it comes to SOAP message processing (except for a PI which we are happy
> > to skip:)).
> > IMHO you will probably need to reinstate the OMDocument if full infoset
> > support is needed!
> >
>
> Eran,
>
> 1. Given that we need to implement full infoset support, do we still
> think OMDocument and PIs are such bad things? :)
>
> 2. As i mentioned, the StaxOMBuilder is already instantiating
> OMDocument on the START_DOCUMENT event. I hope you meant the same by
> "reinstating OMDocument"?
>
> 3. What do you think about moving child node API from OMElement to
> OMNode and OMDocument implementing OMNode?
>
> - venkat
>
> >
> > On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
> > > Before i talk about the problem, Eran, i see that we are still
> > > creating the OMDocument and setting the first ELEMENT_NODE as its
> > > rootElement. - isn't it?
> > >
> > > The problem as i understood:
> > >
> > > There are stuff other than root element (envelop) that need go as
> > > children into the OMDocument object. Currently this is not possible
> > > because OMDocument isn't designed to contain anything other than
> > > rootElement.
> > >
> > > Possible solutions:
> > >
> > > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > > from OMElement to OMNode. I think this is preferable becaus the
> > > addChild, getChild sort of methods seem more natural to OMNode than
> > > OMElement. OMElement can have addChildElement etc, if needed.
> > >
> > > 2. Make OMDocument to extend OMElement, but i think this is an
> > > overkill, because the Document object isn't really an XML element.
> > >
> > > I didn't understand why we need Object or OMContainer as parent. May
> > > be i'm missing something.
> > >
> > > - venkat
> > >
> > >
> > > On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
> > > > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > > > > Hi devs!
> > > > >
> > > > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > > > This appears problematic. Because for document level comments (i mean,
> > > > > comments that are present outside the root element in the XML
> > > > > document) parent becomes OMDocument rather than OMElement. So better
> > > > > have the 'parent' data member as Object. And accordingly the return
> > > > > type of getParent will be Object. I hope this change will not break
> > > > > any existing code, will it???
> > > >
> > > > This will not break any of the code. But this will add some bad
> > > > things, IMHO, to code. For example, anything can be a parent of any
> > > > node, even a Text node.
> > > > That was the main reason why, we purposely made parent to an OMElement.
> > > >
> > > > I understand your concern, but ............
> > > >
> > > > And there is another question coming from me, is it necessary to
> > > > provice the ability to add comments to the Document which is even out
> > > > of the document element ??
> > > >
> > > > Making this available is of not that useful, but will add some weird
> > > > look to the code.
> > > >
> > > > We earlier had the concept of OMDocument, but later removed it.
> > > >
> > > > For your all information : These days all the Sri Lankan people have
> > > > gone home to celebrate our Sinhalese new year festival. So, there may
> > > > be (including me), a deley in replying to the mails. :(
> > > >
> > > > Regards,
> > > > Chinthaka
> > > >
> > > > >
> > > > > Jaya
> > > > > --
> > > > > -- Jaya
> > > > >
> > > >
> > > > --
> > > >
> > --------------------------------------------------------
> > > > Eran Chinthaka
> > > >
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
>
--
-- Jaya
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
On 4/18/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi,
> I guess this is another facet of the SOAP vs pure XML problem :). The reason
> why we are not so keen on having an OMDocument is that it is just redundant
> when it comes to SOAP message processing (except for a PI which we are happy
> to skip:)).
> IMHO you will probably need to reinstate the OMDocument if full infoset
> support is needed!
>
Eran,
1. Given that we need to implement full infoset support, do we still
think OMDocument and PIs are such bad things? :)
2. As i mentioned, the StaxOMBuilder is already instantiating
OMDocument on the START_DOCUMENT event. I hope you meant the same by
"reinstating OMDocument"?
3. What do you think about moving child node API from OMElement to
OMNode and OMDocument implementing OMNode?
- venkat
>
> On 4/15/05, Venkat Reddy < vreddyp@gmail.com> wrote:
> > Before i talk about the problem, Eran, i see that we are still
> > creating the OMDocument and setting the first ELEMENT_NODE as its
> > rootElement. - isn't it?
> >
> > The problem as i understood:
> >
> > There are stuff other than root element (envelop) that need go as
> > children into the OMDocument object. Currently this is not possible
> > because OMDocument isn't designed to contain anything other than
> > rootElement.
> >
> > Possible solutions:
> >
> > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > from OMElement to OMNode. I think this is preferable becaus the
> > addChild, getChild sort of methods seem more natural to OMNode than
> > OMElement. OMElement can have addChildElement etc, if needed.
> >
> > 2. Make OMDocument to extend OMElement, but i think this is an
> > overkill, because the Document object isn't really an XML element.
> >
> > I didn't understand why we need Object or OMContainer as parent. May
> > be i'm missing something.
> >
> > - venkat
> >
> >
> > On 4/12/05, Eran Chinthaka <chinthakae@gmail.com > wrote:
> > > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > > > Hi devs!
> > > >
> > > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > > This appears problematic. Because for document level comments (i mean,
> > > > comments that are present outside the root element in the XML
> > > > document) parent becomes OMDocument rather than OMElement. So better
> > > > have the 'parent' data member as Object. And accordingly the return
> > > > type of getParent will be Object. I hope this change will not break
> > > > any existing code, will it???
> > >
> > > This will not break any of the code. But this will add some bad
> > > things, IMHO, to code. For example, anything can be a parent of any
> > > node, even a Text node.
> > > That was the main reason why, we purposely made parent to an OMElement.
> > >
> > > I understand your concern, but ............
> > >
> > > And there is another question coming from me, is it necessary to
> > > provice the ability to add comments to the Document which is even out
> > > of the document element ??
> > >
> > > Making this available is of not that useful, but will add some weird
> > > look to the code.
> > >
> > > We earlier had the concept of OMDocument, but later removed it.
> > >
> > > For your all information : These days all the Sri Lankan people have
> > > gone home to celebrate our Sinhalese new year festival. So, there may
> > > be (including me), a deley in replying to the mails. :(
> > >
> > > Regards,
> > > Chinthaka
> > >
> > > >
> > > > Jaya
> > > > --
> > > > -- Jaya
> > > >
> > >
> > > --
> > >
> --------------------------------------------------------
> > > Eran Chinthaka
> > >
> >
>
>
>
> --
> Ajith Ranabahu
Re: [Axis2] OMNodeImpl notes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
I guess this is another facet of the SOAP vs pure XML problem :). The reason
why we are not so keen on having an OMDocument is that it is just redundant
when it comes to SOAP message processing (except for a PI which we are happy
to skip:)).
IMHO you will probably need to reinstate the OMDocument if full infoset
support is needed!
On 4/15/05, Venkat Reddy <vr...@gmail.com> wrote:
>
> Before i talk about the problem, Eran, i see that we are still
> creating the OMDocument and setting the first ELEMENT_NODE as its
> rootElement. - isn't it?
>
> The problem as i understood:
>
> There are stuff other than root element (envelop) that need go as
> children into the OMDocument object. Currently this is not possible
> because OMDocument isn't designed to contain anything other than
> rootElement.
>
> Possible solutions:
>
> 1. Make OMDocument to extend OMNode, and move the addChild* methods
> from OMElement to OMNode. I think this is preferable becaus the
> addChild, getChild sort of methods seem more natural to OMNode than
> OMElement. OMElement can have addChildElement etc, if needed.
>
> 2. Make OMDocument to extend OMElement, but i think this is an
> overkill, because the Document object isn't really an XML element.
>
> I didn't understand why we need Object or OMContainer as parent. May
> be i'm missing something.
>
> - venkat
>
>
> On 4/12/05, Eran Chinthaka <ch...@gmail.com> wrote:
> > On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > > Hi devs!
> > >
> > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > This appears problematic. Because for document level comments (i mean,
> > > comments that are present outside the root element in the XML
> > > document) parent becomes OMDocument rather than OMElement. So better
> > > have the 'parent' data member as Object. And accordingly the return
> > > type of getParent will be Object. I hope this change will not break
> > > any existing code, will it???
> >
> > This will not break any of the code. But this will add some bad
> > things, IMHO, to code. For example, anything can be a parent of any
> > node, even a Text node.
> > That was the main reason why, we purposely made parent to an OMElement.
> >
> > I understand your concern, but ............
> >
> > And there is another question coming from me, is it necessary to
> > provice the ability to add comments to the Document which is even out
> > of the document element ??
> >
> > Making this available is of not that useful, but will add some weird
> > look to the code.
> >
> > We earlier had the concept of OMDocument, but later removed it.
> >
> > For your all information : These days all the Sri Lankan people have
> > gone home to celebrate our Sinhalese new year festival. So, there may
> > be (including me), a deley in replying to the mails. :(
> >
> > Regards,
> > Chinthaka
> >
> > >
> > > Jaya
> > > --
> > > -- Jaya
> > >
> >
> > --
> > --------------------------------------------------------
> > Eran Chinthaka
> >
>
--
Ajith Ranabahu
Re: [Axis2] OMNodeImpl notes
Posted by Venkat Reddy <vr...@gmail.com>.
Before i talk about the problem, Eran, i see that we are still
creating the OMDocument and setting the first ELEMENT_NODE as its
rootElement. - isn't it?
The problem as i understood:
There are stuff other than root element (envelop) that need go as
children into the OMDocument object. Currently this is not possible
because OMDocument isn't designed to contain anything other than
rootElement.
Possible solutions:
1. Make OMDocument to extend OMNode, and move the addChild* methods
from OMElement to OMNode. I think this is preferable becaus the
addChild, getChild sort of methods seem more natural to OMNode than
OMElement. OMElement can have addChildElement etc, if needed.
2. Make OMDocument to extend OMElement, but i think this is an
overkill, because the Document object isn't really an XML element.
I didn't understand why we need Object or OMContainer as parent. May
be i'm missing something.
- venkat
On 4/12/05, Eran Chinthaka <ch...@gmail.com> wrote:
> On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> > Hi devs!
> >
> > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > This appears problematic. Because for document level comments (i mean,
> > comments that are present outside the root element in the XML
> > document) parent becomes OMDocument rather than OMElement. So better
> > have the 'parent' data member as Object. And accordingly the return
> > type of getParent will be Object. I hope this change will not break
> > any existing code, will it???
>
> This will not break any of the code. But this will add some bad
> things, IMHO, to code. For example, anything can be a parent of any
> node, even a Text node.
> That was the main reason why, we purposely made parent to an OMElement.
>
> I understand your concern, but ............
>
> And there is another question coming from me, is it necessary to
> provice the ability to add comments to the Document which is even out
> of the document element ??
>
> Making this available is of not that useful, but will add some weird
> look to the code.
>
> We earlier had the concept of OMDocument, but later removed it.
>
> For your all information : These days all the Sri Lankan people have
> gone home to celebrate our Sinhalese new year festival. So, there may
> be (including me), a deley in replying to the mails. :(
>
> Regards,
> Chinthaka
>
> >
> > Jaya
> > --
> > -- Jaya
> >
>
> --
> --------------------------------------------------------
> Eran Chinthaka
>
Re: [Axis2] OMNodeImpl notes
Posted by Eran Chinthaka <ch...@gmail.com>.
On Apr 12, 2005 12:58 PM, jayachandra <ja...@gmail.com> wrote:
> Hi devs!
>
> Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> This appears problematic. Because for document level comments (i mean,
> comments that are present outside the root element in the XML
> document) parent becomes OMDocument rather than OMElement. So better
> have the 'parent' data member as Object. And accordingly the return
> type of getParent will be Object. I hope this change will not break
> any existing code, will it???
This will not break any of the code. But this will add some bad
things, IMHO, to code. For example, anything can be a parent of any
node, even a Text node.
That was the main reason why, we purposely made parent to an OMElement.
I understand your concern, but ............
And there is another question coming from me, is it necessary to
provice the ability to add comments to the Document which is even out
of the document element ??
Making this available is of not that useful, but will add some weird
look to the code.
We earlier had the concept of OMDocument, but later removed it.
For your all information : These days all the Sri Lankan people have
gone home to celebrate our Sinhalese new year festival. So, there may
be (including me), a deley in replying to the mails. :(
Regards,
Chinthaka
>
> Jaya
> --
> -- Jaya
>
--
--------------------------------------------------------
Eran Chinthaka