WORK ITEMS STILL TO BE DONE

* Support document-start-actions, document-end-actions
* Object binding work:
  - allow a factory to instantiate it (including a factory of processing 
    instructions (i.e., "declare-binding"). 
  - support resetting of bound object references: ie., re-save the reference
    at the end of each action.
* Support libraries
* Support downward element references with some subset of XPATH expressions
  - currently only attribute for the element context are supported
* Support multiple matches on content; support matching on attribute values 
  as well as element names. As part of this, remove the requirement that 
  there be a DTD for the inbound or outbound XML. 
  - it might be good to support XPath query langauge or XQL expressions.
  - support extracting mixed content: e.g., the part of the element text value
    before a particular subelement.
* Allow access to DOM subtrees of elements to the java code in processing 
  actions. 
* Support for processor "delegation" and "chaining".
  - "delegation": submitting an element subtree to another processor; when the 
    subprocessor completes, control is returned to the parent processor
  - "chaining": handing off control of the processing to another processor; 
    does not return to parent processor.
* Allow reg expressions in "value=" validation
* Better error handling (see REVIEW in ProcessorCompiler)
* Multiple validation errors (compiler switch or should it go in the 
  processing instructions?)
* Have the process() method in the generated code take an InputStream from
  which to read XML input and an OutputStream on which to write XML output.
* Implement processor registry - see comments in ProcessorFactory
* Write examples:
  - cell phone number directory synchronization application 
  - SOAP (processor delegation)
  - data binding
* Terminology problems: There is a conflict between the generic term 
  "processor" and the specific types, namely: "processors" (also known as 
  "in-processors" that consume XML and perform Java actions and "generators" 
  (also known as "out-processors" that generate XML. I don't much like
  the terms "in-processor" and "out-processor". Perhaps better names
  would be "XML consumer" and "XML producer" which would both be
  subsumed under the name "XML processor"? 
* Support optional validation of XML output using a parser. This would
  be most useful in debugging generators. Compile time option.
* Incorporating generators/XMLProducers/out-processors into a registry and 
  factory. 
* XML pretty-printing: compile time option

IDEAS FOR FUTURE:

* Make processor and generators call SAX Document handlers
* Allow the generator output to be chained into an XSLT processor
  - would require wrapping an XSLT engine with an XMLProcessor
