diff --git a/docs/ant2/requested-features.txt b/docs/ant2/requested-features.txt
index 52fa11057..2117d88c9 100644
--- a/docs/ant2/requested-features.txt
+++ b/docs/ant2/requested-features.txt
@@ -251,6 +251,9 @@ decide between several possible options.
 V. Things we probably don't agree on. 
 ======================================================================
 
+[DISC] Datatypes
+----------------
+
  * Allow mappers to be genericised so that particular features can be modified 
  during mapping. Something similar to 
  
@@ -279,8 +282,6 @@ V. Things we probably don't agree on.
                 value="29th Feb 2003"/>
  </include>
 
-  2003 is no leap year 8-)
-
 * provide datatypes through property tag and remove need for separate free
   standing entities. ie
   <property name="foo">
@@ -289,45 +290,90 @@ V. Things we probably don't agree on.
     </fileset>
   </property>
 
+* provide support for non-hardwired (ie loadable) low-level 
+ components (mappers/itemset-filters/converters). Allow them to be 
+ loaded in either global or a new classloader.
+
+* provide support for non-hardwired (ie loadable) converters.
+
+  Q: What is a converter? Is this an implementation detail?
+  A: Not an implementation detail but a way to extend the engine
+  to convert more data types. Currently we have fixed set that is 
+  expanded on occasion (ie includes primitive types + File). Instead
+  of spreading converting code through out tasks it can be centralized 
+  into one component and used by engine. This becomes particularly 
+  relevent if you build ant based testing systems and use ant in certain
+  web-related areas.
+
+* Make all datatypes interfaces to allow them to be customized in many
+  ways.
+
+* Set arithmetic for fileset/patternset/*set
+
+* inheritance of ant properties/datatypes/context etc in project hierarchy
+
+* inheritance of between ant datatypes. ie fileset A inherits from fileset B (includes 
+  all entries in A).
+
+* Homogenize notion of PATHs and filesets.
+
+[DISC] Ant's goals
+------------------
+
 * make it possible to reuse taskengine for other things. ie
   Installshield type app, Peter's cron-server and other task based
   operations. 
 
- * provide support for non-hardwired (ie loadable) low-level 
- components (mappers/itemset-filters/converters). Allow them to be 
- loaded in either global or a new classloader.
+* provide support for CJAN
+
+  Q: In what way?
+  A: Probably by supplying a set of tasks that download versioned 
+  binaries and their associated dependencies, caching the downloads
+  in a known place and updating binaries when required. ("When required"
+  being indicated by a change in property values).
+
+[DISC] class loading
+--------------------
 
  * force resolution of classes on loading to identify classloader 
  issues early. (At least in global classloader).
 
+* Ignore any classes contained in the damned ext dirs of a JVM - possibly by launching
+  with something like jar -Djava.ext.dir=foo -jar ant.jar
+
+[DISC] workspace/subbuild issues
+--------------------------------
+
 * create the concept of workspace so that projects can be built in a
   DAG and thus enable projects like catalina/tomcat to have an easy
   build process. It also helps CJAN to a lesser degree and would
   partially solve the JARs in CVS thing.
 
-* provide support for CJAN
+* Project inheritance
 
-  Q: In what way?
-  A: Probably by supplying a set of tasks that download versioned 
-  binaries and their associated dependencies, caching the downloads
-  in a known place and updating binaries when required. ("When required"
-  being indicated by a change in property values).
+  What's this?
 
-* provide support for non-hardwired (ie loadable) converters.
+* Target inheritance. ie The ability to include targets from other 
+  project files overidining them as necessary (so cascading project
+  files).
 
-  Q: What is a converter? Is this an implementation detail?
-  A: Not an implementation detail but a way to extend the engine
-  to convert more data types. Currently we have fixed set that is 
-  expanded on occasion (ie includes primitive types + File). Instead
-  of spreading converting code through out tasks it can be centralized 
-  into one component and used by engine. This becomes particularly 
-  relevent if you build ant based testing systems and use ant in certain
-  web-related areas.
+* Add an attribute to <ant> to feed back the environment (properties and
+  taskdefs) from the child build to the parent.
+
+* Allow a target to depend on a target which is in another buildfile.  
+
+* Allow a target to reference properties defined in another buildfile.
+
+[DISC] documentation system
+---------------------------
 
 * generate docs by anakia/XSLT
 
   Corollary of "move to a system that allows docs to be generated"?
 
+[DISC] Task API
+---------------
+
 * tasks provide some way to identify their attributes from the
   outside. 
 
@@ -337,42 +383,58 @@ V. Things we probably don't agree on.
   should not impose any cost on runtime as it is only used a small 
   proportion of the time (design-time).  
 
+* tasks should have access to its own XML representation.
+
+* Task level if and unless attributes.
+
+* Allow tasks to find out, whether another task has completed successfully.
+
+* provide failonerror like functionality to all tasks. (Provide this as an aspect??
+  much like logging aspect or classloader aspect).
+
+[DISC] logging
+--------------
+
 * allow build file writers to modify logging (verbosity for example)
   on a target by target or task by task basis.
 
-* Simple flow control (if-then-else, for)
+* Make loggers configurable via build.xml.
+
+[DISC] multithrading
+--------------------
 
 * Multithreaded execution of tasks within the same target.
 
 * Multithreaded execution of targets.
 
-* Project inheritance
+[DISC] procedural versus purely declarative
+-------------------------------------------
 
-  What's this?
+* Simple flow control (if-then-else, for)
 
-* Target inheritance. ie The ability to include targets from other 
-  project files overidining them as necessary (so cascading project
-  files).
+* targets should be like methods including a return value
 
-* Add an attribute to <ant> to feed back the environment (properties and
-  taskdefs) from the child build to the parent.
+* build files should be purely declarative
+
+[DISC] Properties
+-----------------
 
 * Ability to manage scopping of properties in general (ie target/project/workspace).
 
+[DISC] Templates
+----------------
+
 * it should be possible to provide general /(template?)/ build
   specifications, and to declare for a concrete item that it should be
   built according to such a general specification.
 
+[DISC] XML issues
+-----------------
+
 * a built-in mechanism to include build-file fragments - something
   that doesn't use SYSTEM entities at all and therefore is XSchema
   friendly, allows for property expansions ...
 
-* Make loggers configurable via build.xml.
-
-* tasks should have access to its own XML representation.
-
-* Allow named tasks to be defined by <script> elements.
-
 * Let Ant ignore - but warn - if unknown XML elements or attributes
   occur in a build file.
 
@@ -380,6 +442,11 @@ V. Things we probably don't agree on.
   namespace to other components. ie hand doc: elements to the Documentation
   component or log: attributes to Log policy component etc
 
+[DISC] core extensions
+----------------------
+
+* Allow named tasks to be defined by <script> elements.
+
 * specify an onfail task or target that runs in case of a build
   failure.
 
@@ -390,15 +457,19 @@ V. Things we probably don't agree on.
   target - as proposed by Thomas Christen in
   <http://marc.theaimsgroup.com/?l=ant-dev&m=98130655812010&w=2>.
 
-* Task level if and unless attributes.
+* Make if/unless attributes to check for the value of a property, not
+  only its existance.
 
-* Make all datatypes interfaces to allow them to be customized in many
-  ways.
+* check for more than one condition in if/unless attributes.
 
-* Allow tasks to find out, whether another task has completed successfully.
+* provide a way to define the order in which targets a given target
+  depends upon get executed.
 
-* Make if/unless attributes to check for the value of a property, not
-  only its existance.
+* define task contexts that define various common aspects (logging,
+  failure handling ...) and assign them to tasks.
+
+[DISC] organization
+-------------------
 
 * separate CVSes and code hierarchies for
   - task engine [ org.apache.task.* ]
@@ -406,35 +477,8 @@ V. Things we probably don't agree on.
     [ org.apache.ant.* ]
   - core tasks (ie tasks supported by ant contributors) [ org.apache.??? ]
 
-* check for more than one condition in if/unless attributes.
-
-* provide failonerror like functionality to all tasks. (Provide this as an aspect??
-  much like logging aspect or classloader aspect).
+[DISC] misc
+-----------
 
 * internationalization
 
-* Ignore any classes contained in the damned ext dirs of a JVM - possibly by launching
-  with something like jar -Djava.ext.dir=foo -jar ant.jar
-
-* Set arithmetic for fileset/patternset/*set
-
-* inheritance of ant properties/datatypes/context etc in project hierarchy
-
-* inheritance of between ant datatypes. ie fileset A inherits from fileset B (includes 
-  all entries in A).
-
-* Homogenize notion of PATHs and filesets.
-
-* build files should be purely declarative
-
-* provide a way to define the order in which targets a given target
-  depends upon get executed.
-
-* Allow a target to depend on a target which is in another buildfile.  
-
-* Allow a target to reference properties defined in another buildfile.
-
-* targets should be like methods including a return value
-
-* define task contexts that define various common aspects (logging,
-  failure handling ...) and assign them to tasks.