The following is a list of items that need to be completed in Validator. Contributions are welcome!

• Change the validation.xml file semantics to match a more general "bean" validation usage. Currently, the <form-validation>, <formset>, <form>, and <field> elements require a form-centric view of validations. Changing these to <bean-validation> or <validator-config>, <beans>, <bean>, and <property> respectively would allow Validator to be used more easily in non-form based environments. See the 2.0 DTD proposal for specifics.
• The above changes to validation.xml could only apply to Validator's native configuration format. We could add a ValidatorResources constructor that accepts a digester-rules file to allow parsing any XML format into Validator configuration objects. This would allow higher level frameworks like Struts to use configuration semantics specific to their domain.
• ValidatorException is only thrown to indicate configuration and programmer errors yet is a checked exception. ValidatorException should be converted to a RuntimeException to match its real purpose. Furthermore, the exception handling for pluggable validations (ValidatorActions) is not well defined or documented. RuntimeExceptions thrown from ValidatorActions should be propogated out of the Validator framework as is because they indicate programmer error. Checked exceptions thrown from a ValidatorAction should stop validation and be propogated out of the framework for handling as these indicate an unrecoverable system failure. Validation method implementation becomes easier because they can throw SQLException, IOException, etc. instead of wrapping the exception or defining it as a rule failure. This allows clients to reliably distinguish between a normal validation failure (invalid data) and exceptional conditions.