From: Bob Hutchison Date: 2008-12-12T23:10:34+09:00 Subject: Re: Problem parseing a XML - PullParser Hi, On 11-Dec-08, at 12:31 PM, Luc Heinrich wrote: > On 11 déc. 08, at 18:27, Sebastian (syepes) wrote: > >> Ok i get the point, but i don't see how to detect the EOF (Without >> using >> some ugly code) and pass the hole *xml to the Parser. > > I'm still not exactly sure of your exact context, but you don't have > to detect the EOF, just parse and when you reach the end of the > document close the pipe yourself on your end. Just for fun, I tried hacking something together using the pull parser that I wrote. This pointed out one possible issue that is confusing, I'll get to that in a second. How to avoid waiting for an EOF? Count events. Crudely, if you increment the count on a start element event, and decrement on an end element, when the count goes to zero, you've got what you are looking for. This means you are letting the pull parser read the input, you don't do it for the parser. The issue I mentioned... In my pull parser I'm assuming a file or string input, not an IO stream. I take advantage of that by looking ahead a bit. This isn't a problem unless you are using a stream. In my parser's case, it is looking ahead to at least the end of the next line (huge performance thing with files). The confusing effect is with the stream input: Testing:service Critical Normal Testing:service Critical Normal The close of the first SChange element isn't reported until the next line is read, which happens to include the start of the next element. This is a delayed effect that is maybe not the best for a stream input. If you add a blank line between the events the problem goes away (but it'll read the blank line before reporting which shouldn't be a problem). It is possible that this is affecting your testing. Cheers, Bob > > > -- > Luc Heinrich - luc@honk-honk.com > > ---- Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch