You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2006/07/24 19:36:05 UTC
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Hey Sanjiva:
> However, the DOOM approach has an advantage- you get a DOM tree for the
> DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> in fact satisfy them all ;-).
Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
we can't just stream in a "standard" OM from somewhere (as a part of
normal message processing, let's say) and then use DOOM without
converting, right? And if you need to convert you have a performance
problem.
What might be nice is a DOM implementation that truly sits "on top" of
OM, so you could do:
OMElement om;
...
Element dom = DOMWrapper.getDOMElement(om);
Where we'd then have a "wrapper" DOM Element which just delegated calls
to its underlying OM implementation...
Isn't that what we originally talked about when designing OM?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Ruchith:
> IIRC one of the reasons we didn't pick the delegation model was
> because it forces us to hold on to _two_ object structures at the same
> point which didn't sound that cool since we were anyway forced to
> build the complete envelop to pump into WSS4J.
Gotcha, that makes sense. I guess another approach would have been to
just implement DOM directly in the LLOM classes but then that would
always bring in the DOM API too.
> But with DOOM you still get the same features of the LLOM OM impl
> (deferred built ..etc.), a DOM interface with a single object
> structure in memory and we can conveniently move DOOM in axis2 with
> out much of a hit on performance.
Sure, except that it's hard to go back and forth between the two
implementations, because you need to do some kind of translation step.
It's all tradeoffs, I suppose, and there's no perfect solution for all
use cases.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi,
IIRC one of the reasons we didn't pick the delegation model was
because it forces us to hold on to _two_ object structures at the same
point which didn't sound that cool since we were anyway forced to
build the complete envelop to pump into WSS4J.
But with DOOM you still get the same features of the LLOM OM impl
(deferred built ..etc.), a DOM interface with a single object
structure in memory and we can conveniently move DOOM in axis2 with
out much of a hit on performance.
Thanks,
Ruchith
On 7/25/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2006-07-24 at 13:36 -0400, Glen Daniels wrote:
> > Hey Sanjiva:
> >
> > > However, the DOOM approach has an advantage- you get a DOM tree for the
> > > DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> > > in fact satisfy them all ;-).
> >
> > Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
> > we can't just stream in a "standard" OM from somewhere (as a part of
> > normal message processing, let's say) and then use DOOM without
> > converting, right? And if you need to convert you have a performance
> > problem.
> >
> > What might be nice is a DOM implementation that truly sits "on top" of
> > OM, so you could do:
> >
> > OMElement om;
> > ...
> > Element dom = DOMWrapper.getDOMElement(om);
>
> Its nearly the same thing .. you call the DOOM builder giving the pull
> parser from the OM. Just a slight diff in API; result is a DOM element
> (which happens to be an OMElement too but you may not care about that).
>
> > Where we'd then have a "wrapper" DOM Element which just delegated calls
> > to its underlying OM implementation...
> >
> > Isn't that what we originally talked about when designing OM?
>
> We had *lots* of discussion since then on ways of implementing DOOM. If
> you recall we had a proto that did the delegation but that wasn't
> without issues. The current DOOM impl was the final form that we settled
> on and it works very well.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM
Posted by Glen Daniels <gl...@thoughtcraft.com>.
>> OMElement om;
>> ...
>> Element dom = DOMWrapper.getDOMElement(om);
>
> Its nearly the same thing .. you call the DOOM builder giving the pull
> parser from the OM. Just a slight diff in API; result is a DOM element
> (which happens to be an OMElement too but you may not care about that).
The problem is that if you've already built the OM, the pull parser is
essentially deconstructing the build objects into XMLStreamReader
events, which are then used to build (yet another) in-memory model.
Right? That seems a) slow, and b) expensive.
I'll go check the archives for some of that discussion - I'm curious as
to what the issues with just delegating were.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-07-24 at 13:36 -0400, Glen Daniels wrote:
> Hey Sanjiva:
>
> > However, the DOOM approach has an advantage- you get a DOM tree for the
> > DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> > in fact satisfy them all ;-).
>
> Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
> we can't just stream in a "standard" OM from somewhere (as a part of
> normal message processing, let's say) and then use DOOM without
> converting, right? And if you need to convert you have a performance
> problem.
>
> What might be nice is a DOM implementation that truly sits "on top" of
> OM, so you could do:
>
> OMElement om;
> ...
> Element dom = DOMWrapper.getDOMElement(om);
Its nearly the same thing .. you call the DOOM builder giving the pull
parser from the OM. Just a slight diff in API; result is a DOM element
(which happens to be an OMElement too but you may not care about that).
> Where we'd then have a "wrapper" DOM Element which just delegated calls
> to its underlying OM implementation...
>
> Isn't that what we originally talked about when designing OM?
We had *lots* of discussion since then on ways of implementing DOOM. If
you recall we had a proto that did the delegation but that wasn't
without issues. The current DOOM impl was the final form that we settled
on and it works very well.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org