Re: StAX Parser progress

[Arthur Ryman]

Oshani,

Could you please explain the difference
between Axiom and Stax?

The Stax requirement comes from Axis2,
so if Axiom satisfies Axis2 then that sounds like the right approach.

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?

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]

"Oshani Seneviratne" <[EMAIL PROTECTED]>
wrote on 06/19/2006 08:32:57 AM:

> Hi devs,
> 
> This mail is mainly to update you with the progress I've made with
the
> StAX based parser for Woden and to get your comments on the approach
> I'm taking (especially if I'm not heading in the expected direction).
> 
> I initially started parsing a WSDL purely with a StAX XMLStreamReader
> to build the Woden element model. The idea I had, was to cache the
> XMLStreamReader at each and every top level element every time as
they
> are accessed. I wanted to use this cached parser in cases where the
> later elements needed information from previously accessed elements.
> However, I realized that when there are so many nested elements, this
> approach created many parser instances even when it was not required
> (i.e. when those elements could have been accessed with the current
> parser). And this was a major problem when it came to the schema
> validation.
> So IMHO, we need to have a proper object model based on StAX, rather
> than building with a pure cursor/event based StAX approach.
> 
> Therefore, how about using AXIOM instead? Since AXIOM is based on
> StAX, the resulting implementation would be fast and efficient, as
it
> is expected from a StAX parser. If one of the objectives of Woden
is
> to be used in Axis2, I suppose using AXIOM in Woden would not be much
> of a problem :).
> 
> I implemented a prototype OMWSDLReader as an alternative to the
> DOMWSDLReader, and at the moment it can correctly read some of the
> components in the hotel-reservation.wsdl. Parsing for extension
> attributes, imports and includes are yet to be added.
> 
> In the case of schema, I suppose we can stick with XMLSchema as in
the
> current DOM impl. However, the arguments to the XMLSchemaCollection's
> read method posed a problem, and I could only come up with the
> following:
> 
> <code snippet>
> 
> //omElement is an OMElement which contains the <xs:schema> element
> String elementString = omElement.toString();
> byte[] bytes = elementString.getBytes();
> 
> //Deserialize from the byte array
> InputStream inputStream = new ByteArrayInputStream(bytes);
> InputSource inputSource = new InputSource(inputStream);
> 
> XmlSchemaCollection xsc = new XmlSchemaCollection();
> XmlSchema schemaDef = xsc.read(inputSource, null);
> 
> </code snippet>
> 
> This returned the correct XMLSchema as it was there in the WSDL.
> However, unlike as in the DOM impl, apart from the targetNamespace,
> the other namespaces were not there as attributes to <xs:schema>.
I
> wonder whether this could lead to a bug later in the model for schema
> in Woden!
> 
> That's about it for the moment, and I will update more on this as
I go on.
> 
> Please advice whether I should attempt on a pure StAX based parser,
or
> whether the AXIOM based implementation is fine.
> 
> Thanks and Regards,
> Oshani.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>