Hi Michael,
Thanks for your reply. As for your comments:
1. XML11Configuration. After looking through it, I think actually I
can use it directly for StAXStreamReader implementation.
2. XMLPullParserConfiguration use org
.apache.xerces.impl.XMLDocumentScannerImpl as its document scanner to
support pull parser. To avoid Alek's problem, one solution is that I need to
know the XMLDocumentScannerImple implementation details and see when it
stops in parsing process. If the scanner didn't meet my expections, for
example, parsing two StAX events as its one step, then I can prepare proper
buffer to store extra event and information.
Thanks, Wei
On 4/2/07, Michael Glavassevich <[EMAIL PROTECTED]> wrote:
Hi Wei,
Welcome to the list and thanks for sharing your thoughts with everyone. I
think you've got the general idea. Some initial comments below...
"wei duan" <[EMAIL PROTECTED]> wrote on 04/01/2007 09:05:53 AM:
> Hello，Everyone,
> I'm a student applying for SoC project Add support for the
> StAX(JSR-173) cursor API to Xerces-J. Michael suggested I could
> discuss my proposal in the mailing list. So I would like to
> introduce my thoughts and plan on this student project, any comments
> are welcomed. : )
> The abstract description of project is: "To design and
> implement the cursor-based XMLStreamReader (and [image removed]
filtering
> support). It should be possible to accomplish this using XNI by building
the
> XMLStreamReader on top of an XMLPullParserConfiguration."
> Besides XNI, there are several ways to implement StAX interface. For
> example, parse the XML document as raw text and start from scratch,
> including parsing characters, building token, and interpreting
> tokens, and so on. Or to implement a converter from existing DOM or
> SAX interfaces.
The student who we had for GSoC last year implemented those already.
They're useful when you're starting from a SAX or DOM source though you
really need a native solution to get decent performance if you're parsing
the document from a stream.
> However, after reading Xerces sources code, I found
> both SAX and DOM implementations are based on XNI, so it's very
> natural to build StAX on XNI.
> To implement XMLStreamReader, two important preconditions should be
confirmed.
> 1. XML event information can be received.
> 2. The pull style parsing process can be simulated.
> When I look through the XNI interfaces, I found it actually meets
> these two preconditions. The handler interfaces in XNI such as
> XMLDocumentHandler and XMLDTDHandler can get XML events including
> startDocument and endDocument, which can be easily mapped to StAX
> events accordingly. XMLPullParserConfiguration interface in XNI is
> used to represent a parser configuration that can be used as the
> configuration for a "pull" parser, thus the pull parsing process of
> StAX can be simulated by calling "boolean parse(boolean)" method in
> XMLPullParserConfiguration .
> Then I looked through the current Xerces Implementation, I found
> AbstractXMLDocumentParser class implements XMLDocumentHandler,
> XMLDTDHandler, and XMLDTDContentModelHandler interfaces. Both
> AbstractDOMParser and AbstractSAXParser extend from
> AbstractXMLDocumentParser. So I think I can implement an
> AbstractStAXParser extending AbstractXMLDocumentParser to get XML
events.
> For example, code in current AbstractSAXParser:
> public void comment(XMLString text, Augmentations augs) throws
> XNIException {
> try {
> // SAX2 extension
> if (fLexicalHandler != null) {
> fLexicalHandler.comment(text.ch, 0, text.length);
> }
> }
> catch (SAXException e) {
> throw new XNIException(e);
> }
> } // comment(XMLString)
>
> And in my AbstractStAXPaser, it may be implemented like this,
> public class AbstractStAXParser extends AbstractXMLDocumentParser {
> public int m_curEventType;
> public String m_characters;
> ….
> public void comment(XMLString text, Augmentations augs)
> throws XNIException {
> m_curEventType = XMLStreamConstants.COMMENT;
> m_characters = new String(text.ch, text.offset,
text.length);
Where possible you should try to avoid creating new strings unless a call
to the API demands one.
> }
> …
> }
>
> Meanwhile, XMLPullParserConfiguration will be used to control the
> parsing process. XML11Configuration is the implementation of
> XMLPullParserConfiguration interface in Xerces.
It's one of several parser configurations which implement
XMLPullParserConfiguration. Given the way we implemented XInclude
(dispatching a child pipeline to read the entire include before returning
to the parent), XML11Configuration is probably a better choice than
XIncludeAwareParserConfiguration (the current default config for SAX and
DOM).
> I think I can implement StAXPaserConfiguration which extends from
> XML11Configuration for XML1.0 and XML 1.1.
I'm not sure why you would need a new parser configuration. I think
XML11Configuration would work just fine. Is there something that you think
is missing from it?
> In runtime, AbstractStAXParser will be set as the handlers of the
> StAXParserConfiguration instance.
> As for XMLStreamReader, it can be implemented as this,
> public class StAXXMLStreamReaderr implements XMLStreamReader {
> public StAXPaserConfiguration m_configuration;
> public StAXParser m_parser;
> ….
> int getEventType()
> {
> return m_parser.m_curEventType;
> }
> int next()
> {
> m_configuration.parse(false)
> return m_parser.m_curEventType;;
> }
> …
> }
I don't think the StAX and XNI method signatures overlap with each other.
You could probably merge this into the other class and avoid the
indirection.
public class AbstractStAXParser
extends AbstractXMLDocumentParser
implements XMLStreamReader {
...
}
> Above are some of my rough thoughts, so if you have any
> comments and questions, I would like to discuss with you.
>
> Thanks, Wei
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
