<?xml version="1.0"?>
<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<document xmlns="http://maven.apache.org/XDOC/2.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
  <properties>
    <title>TODO</title>
  </properties>

  <body>
    <section name="TODO list">
      <p>
        The following is a list of items that need to be completed in
        Validator.  Contributions are welcome! 
      </p>

      <ul>
        <li>
          Change the validation.xml file semantics to match a more general "bean" validation usage.
          Currently, the &lt;form-validation&gt;, &lt;formset&gt;, &lt;form&gt;, and &lt;field&gt; elements
          require a form-centric view of validations.  Changing these to &lt;bean-validation&gt; or &lt;validator-config&gt;, 
          &lt;beans&gt;, &lt;bean&gt;, and &lt;property&gt; respectively would allow Validator to be used more easily in
          non-form based environments. See the 2.0 DTD <a href="validator_2_0_0_proposal.dtd">proposal</a> for specifics.
        </li>
        <li>
            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.
        </li>
        <li>
            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.
        </li>
      </ul>

</section>
</body>
</document>
