Arthur Ryman wrote: > Oshani, Can I intervene here a bit, as I'm familiar with Axiom.
> > Could you please explain the difference between Axiom and Stax? StAX is simply the parser and Axiom is the object model which uses StAX apis to read and write. > > The Stax requirement comes from Axis2, so if Axiom satisfies Axis2 then > that sounds like the right approach. Its not only that. Oshani needs to go back and forward. But she can not do that with an event driven appraoch. Obviously she needs to build an object model. Since Axiom is such an object model, which runs on top StAX, and has the deferred building capability, it is the best solution for this situation. > > The end result of the parse should be an object model that implements the > Woden interface. The underlying implementation for Stax is, I assume, more > light weight than DOM. Is it demand driven too? i.e. is reading the > documents defered until a request is made on the Woden API? Yes Axiom is demand driven. Let me try to understand the situation. There can be two ways to implement this. 1. To implement Woden object model extending Axiom elements. This is what I did to implement SOAP on top of Axiom (Axiom is a pure XML info set representation). 2. Build the Axiom object model from the parser and to use that to populate the Woden model. First approach is preferred as it won't create two object models. But this requires some one to re-implement Woden object model. So the best short term option is to go for the second option, IMO. -- Chinthaka
signature.asc
Description: OpenPGP digital signature
