Bob
Holliday, Donald B. (LNG-CSP) wrote:
I guess you didn't notice that Andy specifically requested that you reply on the Xerces-J Dev list (xerces-j-dev). That's where he wants to carry on a discussion of this topic. Not on the user list.
Thanks,
Donald Holliday
-----Original Message----- From: Bob Foster [mailto:[EMAIL PROTECTED] Sent: Sunday, October 05, 2003 11:41 PM To: [EMAIL PROTECTED] Subject: Re: [Discuss] Pull Parsing, JSR-173, and Xerces
Andy Clark wrote:
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.
After a very cursory reading, I'd be inclined to agree. But I'm a sucker for designed-in performance arguments and I recognize that others are unconvinced by hypothetical performance; you have to whack 'em over the head with a benchmark or two. Are there any realistic prototypes of the JSR proposal vs. your suggestion? I'm sure what you suggest is faster; I'm not sure how much.
One glaring problem does jump out, though. Section 4.5.1, XMLInputFactory, describes yet another non-threadsafe parser configuration. It seems insane that an application can't control its own class loading in a threadsafe way. This one is even worse than the SAX API - _none_ of the ways to configure what gets loaded is threadsafe, nor is there any way for an application to disable any of them. Is it too late to fix this?
Bob Foster http://www.xmlbuddy.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
