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