Eli, seeing our discussion so far, ISTM that the parser-target interface is at the very heart of our disagreement.

For me, it's a good design that provides a clean separation of concerns between the parser that generates events, and the target (usually, but not necessarily a TreeBuilder) that processes them. The link back is then provided by the close() method (provided by both, BTW), which terminates the parsing process and passes the result through to the user. That result may be a tree, but that's completely up to the target, and whatever comes back is transparent to the parser (there's an example of that in the docs, BTW). That's a clean separation of concerns that I would like to copy in the design of the XMLPullParser (in fact, by inheriting from XMLParser). Extrapolating this exact design, whatever comes back from the callback methods should be transparent to the parser and should control the objects that the XMLPullParser collects for its events. I.e., it's the target's sole responsibility to convert the parser's calls into objects that make up both the collected events and the result returned by the parser's close() methods. Again, I consider this a very clean separation of concerns.

Essentially, I embrace the fact that the user is standing on both sides of the API and can control both the generation of the event objects (by providing a target object) and the processing of the events in front of the parser. To me, this is a very clean and extremely flexible design, and I hope it's clearer now why I consider it an excellent feature.

Now, several of your comments so far indicate an aversion towards the parser-target interface because it allows arbitrary objects to be returned by uncontrollable, user provided code, thus "tainting" the otherwise clean tree building interface of the new pull parser. On the other hand, you also stated that you would like to keep a separation between the parser and the TreeBuilder and do not want the parser to know about trees, so I guess that means that you also wouldn't want the parser to enforce any kind of tree building constraints on whatever the result of the parsing process is. As I said before, it's utterly unclear to me how both of these go together, but that's what I could extract from the discussion so far.

Would it be possible for you to clarify your own opinion on this topic, and, specifically, how you envision the role of the parser, the target and their separation of concerns during the event generation? I think this would help us get this discussion a little forward.