]> &people; The heart of parsing XML documents is the interaction between the various scanners and the document input stream. Since this is the critical path in the parser, performance is an important consideration. Yet, at the same time, the interaction between scanner and reader should be simple and straightforward. Entity stack management. The scanners can push readers on the stack when an entity reference is seen but who pops the reader? Who scans the XMLDecl and TextDecl lines? The scanner(s) or the entity reader? Handling the changing of the input stream reader based on the encoding specified in the XMLDecl or TextDecl lines. How do we handle the pushback buffer needed at certain times during parsing while still keeping the amount of delegation down to a minimum? The parser is designed as a pipeline and the components need to be connected together and configured. Is there a generic way to put components together in order to construct the pipeline? If users want to construct a new parser object with a different pipeline configuration, this should be easy to do. There are many emerging XML standards that involve operations on the XML Infoset. XInclude is one of these standards that defines how XML inclusion operates on the Infoset. When should these operations take place in the parser pipeline: before or after validation? And if it's after validation, then what does it mean for the parser to say a document is "valid"? The inclusion could cause the document to become invalid. This is more than an implementation issue; it's a standards issue. If XInclude processing were called after validation, then what would be validated would be the unexpanded XInclude. In other words, the schema or DTD would describe the original unexpanded xinclude:href attributes, and so forth. Should operations on the XML Infoset even be in the parser pipeline?