Pull Parsing, JSR-173, and Xerces 2003-10-06 - By Andy Clark
With the recent public review of JSR-173, the Streaming
API for Java, I've been hoping for more of a discussion
among Apache users and developers regarding this API
and pull parsing in general. But there seems to have
been an amazing amount of apathy in this regard. So I
would like to kickstart the discussion.
I am concerned that the API, as it stands, will not
adequately meet the needs of XML developers. Moreover,
I have concerns about implementing it efficiently in
the Xerces parser. But I'll let others comment on the
technical (de)merits of the API because I want to take
this opportunity to discuss what I would like to see
in a pull parser design.
There are two camps of thought in JSR-173: one that
wants a single interface iterator model and another
that wants discrete event objects to represent the
various parts of the document. The first is designed
with small footprint in mind while the second is more
OO and allows apps to conveniently save document
content.
To appease both camps, JSR-173 includes both approaches
in the API. This is wrong. Users would be better served
by a single, simpler, more integrated approach.
I favor the event approach with the fundamental change
that the event objects returned are singletons owned
by the parser. If the application wants the information
stored within the object, the app must copy the info out
of the singleton and save it.
This approach would appease those developers concerned
with memory (e.g. people targeting J2ME) while providing
a straightforward OO model for everyone else. The counter
argument is that users of the API would be confused about
who owns the memory and try to keep references to objects
whose content is transient. But I disagree.
While it may cause some people trouble the first time
they sit down to write an app, they quickly learn the
paradigm and move on. As we all know, DOM has "live" node
lists. That's the model. You may trip over it the first
time but then you learn it and move on.
And providing a clone method allows applications to keep
references to event objects if they choose. So this would
be a way to provide that functionality as well while
maintaining a single, integrated model which I think is
paramount.
I'll provide more details as the discussion develops but
now I'd like to see what other people think. If you need
to catch up with what I'm talking about, you can check
out the following URLs regarding JSR-173:
http://www.jcp.org/en/jsr/detail?id=173
http://jcp.org/aboutJava/communityprocess/first/jsr173/index.html
One last thing: even though I'm cc'ing xerces-j-user, I
would like to keep this discussion on the xerces-j-dev
list. So if you'd like to contribute your two cents and
you're not already subscribed to the xerces-j-dev list,
do that now.
--
Andy Clark * andyc@(protected)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@(protected)
For additional commands, e-mail: xerces-j-user-help@(protected)
|
|
