axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: [Axis2] OM - Traversal of children from parent
Date Thu, 30 Sep 2004 15:24:12 GMT
>From an XML -> Java/C++ data binding sense, I don't see random
access as likely.

However, for services that are messing with the XML (which IMO
is the future) then random access thru XPath is very likely.
Then the question becomes how efficiently can an XSLT engine
use our OM? Good question. I have no idea .. maybe we should
(at some point) look into Xalan integration for the OM.

(Of course applications can directly do XPath queries via JXPath
etc. - so we should try to support XPath on top of OM too at
some point .. could be good projects for new people!)


----- Original Message ----- 
From: "Eran Chinthaka" <>
To: <>; "'Ajith Ranabahu'" <>
Sent: Thursday, September 30, 2004 11:30 AM
Subject: RE: [Axis2] OM - Traversal of children from parent

> Thinking more on this, I have one point, which is actually against my
> suggestion :)
> If we look at the way, DOM api provides access to children through parent
> that, first one has to call the getChildNodes() which returns a NodeList
> then one has iterate through that NodeList, sequentially to get to the
> required child.
> This is the normal case. But NodeList has methods to get specific child by
> giving the index, but I don't think anyone will be using that method to
> access the SOAP message.
> Since this is the case, if our concern is to improve performance in DOM
> only, my proposal has no value in performance concerns for DOM api on
> But if you take the getLastChild() method, then my proposal is good for
> documents.
> ________________________________
> Eran Chinthaka
> Lanka Software Foundation
> -----Original Message-----
> From: Ajith Ranabahu []
> Sent: Thursday, September 30, 2004 11:03 AM
> To:
> Subject: Re: [Axis2] OM - Traversal of children from parent
> Hi
> Well I should say Chinthaka has a point. The original idea of throwing
> away some features of the DOM (at least in the storage) is to reduce
> the use of collection classes and improve the memory footprint. some
> implementations that are now in the scratch right now go along with
> this concept (that is minimize the memory footprint by avoiding the
> use of collection classes). I guess that is what Glen refers to as the
> "shim DOM"
> As far as I understand the thoughts that led to the decision of a
> "shim DOM" instead of a full DOM are as follows.
> The DOM is to be built by pull parsing in a step-by-step manner. The
> objects are created as and when required.
> However the advantage gained by this sort of "defered building" can be
> deteriorated if the created objects are really heavy. Hence we need a
> light weight object representation as well.
> So we try to retain what is absolutely necessary to recreate the
> infoset of the document. (the parent-to-all-children relationship is
> not absolutely necessary. instead the parent has a reference to the
> first child and each of the children has a referece to the next
> sibling in most of our prototype OMs) This is not really "developer
> friendly". It is a fact that higher levels of abstraction provides
> less efficient code so if we want to improve the performace then
> inevitably we will have to deal with code in a much lower level. So
> our OM's lack certain straight-forward accessing methods (such as the
> list of children of a parent).
> the fact that whether we should have a complete Object structure (such
> as DOM or JDOM)  or just a "shim DOM" depends on the kind of documents
> we are dealing with. If the documents are huge then a heavy object
> structure is disadvantegeous. On the otherhand smaller documents will
> be much easier to handle with a full DOM since the memory footprint is
> not likely to be a major issue (due to the fact that documents are
> smaller and produce fewer objects).
> Just as Alek suggests we have to measure the performance and decide
> which "optimization" we need.
> My guess is Chinthaka is already writing a performace bench based on
> the Sosnoski bence mark.
> -- 
> Ajith Ranabahu

View raw message