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

• Integrate the creation of javascript javadocs into the maven build. What will need to happen is something similar to the exec task in the ant build.xml. Then to put a Maven template around the javadoc it and the legacy 1.0.2 javadoc will need to be copied to a temporary directory then the html2xdoc task will need to be run against that temporary directory.
• 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.
• Examine the need for all dependencies. Validator has many dependencies that are very lightly used and could be removed. Two likely candidates for removal are commons-collections and ORO. The first because Validator only uses one class in a very large jar and backward incompatible changes in recent versions. The second because it can easily be replaced with the faster and standard Java 1.4 regex engine.
• Scenario one: Replace the Jakarta ORO regex engine with the standard Java 1.4 engine. Preliminary tests show a 50% speed improvement using the standard engine. This will remove the ORO dependency and bring Validator in line with standard Java regular expressions. However, this requires a move to Java 1.4 as the base required Java version. A good time for this move may be Validator 2.0 when we also change the configuration file semantics.
• Scenario two: ORO provides a much richer interface to regular expressions, such that we don't have to worry about bit twiddling, this includes a pluggable regex engine. Jeffrey E Friedl states in Mastering Regular Expressions 2ed, says that in speaking to the ORO developers that they will likely develop an adapter to the Java 1.4 regex, See page 378. So we get use of ORO and the speed of Java 1.4 Regex engine.
• 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.