Brad O'Hearne wrote: > Again, I hate to sound picky, but a seemingly small compromise on #2 is one > of those things that over time can lead to a whole list of caveats (and
You're not being picky; it's important that we define what the behavior is and then document it. I think I added some Javadoc concerning this to the parse method recently. Unfortunately, it's on XMLParser in the framework package so most people probably won't see it. Anyway, I agree with your point #2. The state of the stream should be the same as when it was passed in (with the obvious exception that we've now read through the document) and the caller is responsible for closing streams that they opened directly. The difference is with streams that are opened automatically by the parser (or by the entity resolver at the request of the parser). Those streams the application never had a handle for and so, therefore, should be closed by the parser. I included the entity resolver even though it is registered by the application because that would require some bizarre communication and state mgmt in order to properly close the stream that was opened by the entity resolver. -- Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
