Hello Sebastian, let me share my ideas inspired by your post. First of all, I'm confused why there is the 'event' term is used if one needs to call 'next' method to get the next one? It looks like this is a good word here though, but it should be used more sequentially. In a current installment you can safely omit this word and think of your XMLReader as a std::copy(std::input_iterator<XMLObject>(std::cin), std::input_iterator<XMLObject>(), MyIteratorAdapterForXMLObject()); where MyIteratorAdapterForXMLObject - is a user defined iterator that do the actual processing. Of course, this view is simplistic, but hope you catch the point: There is no place for the Event concept! But don't get me wrong, please, my point is that Boost.XML should be made around the real Event concept. My background here is ACE Reactor components (events demultiplexing subsystem) and more recent Boost.Channel proposal by Yigong Liu (search boost list for "another snapshot release of Channel framework") In this light, the proper programming model for XML parsing would be general event demultiplexing system, with XMLReader seen as a source of XML events, DTD and Scheme Validators as an event filters (and sources of Validation events too) and user code as event sinks and/or filters (of course in such an environment it would be a good way to implement all other program logic by event sending and responding to them, but it is up to user and not you as an XML parsing library implementor). The whole XML processing system would be a collection of Streams (in ACE terms Stream is a chain of event filters rooted in event sources and ended in event sinks). Of course the whole system can operate asynchronously and optionally in a distributed environment. To conclude, I suggest you to take a look at ACE and try to figure out how it can be useful to accomplish your goal. Thank you for your interest in developing such a library for boost, Oleg Abrosimov.