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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
