Re: [Axis2] OMNodeImpl notes

[Aleksander Slominski]

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 <[EMAIL PROTECTED]> wrote:

On 4/18/05, Ajith Ranabahu <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > wrote:

On Apr 12, 2005 12:58 PM, jayachandra <[EMAIL PROTECTED]> 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