-
-
-TO DO
------
-
-* Add proximity support to parser -- just the back-ends left to do.
-
-* Relation modifiers could be limited to known modifiers only.
-
-* Fix CQLParser and CQLLexer shell-script front-ends to elegantly
- handle their classes' test harnesses' ability to read the query from
- the command-line arguments, if any, falling back to stdin if there
- are none.
-
-* Add CQLGenerate shell-script. Allow CQLGenerate test-harness to
- take some arguments on command-line as well as or instead of a
- file.
-
-* Trivial CQLCanonicalise application, which renders out its source
- tree in a canonical form, enabling queries to be diffed for
- semantically significant differences only. Tests can be run by
- generating random trees, canonicalising them, then canonicalising
- them _again_ and checking that the before-and-after results are the
- same.
-
-* Some niceties for the cql-decompiling back-end:
- * don't emit redundant parentheses.
- * don't put spaces around relations that don't need them.
-
-* Write pqn-generating back-end (will need to be driven from a
- configuation file specifying how to represent the qualifiers,
- relations, relation modifiers and wildcard characters as z39.50
- attributes.)
-
-* Consider the utility of yet another back-end that translates a
- cqlnode tree into a type-1 query tree using the jzkit data
- structures. That would be nice so that CQL could become a JZKit
- query-type, but you could achieve the same effect by generating PQN,
- and running that through JZKit's existing PQN-to-Type-1 compiler.
-
-* Refinements to random query generator:
- * Generate relation modifiers
- * Proximity support
- * Don't always generate qualifier/relation for terms
- * Better selection of qualifier (configurable?)
- * Better selection of terms (from a dictionary file?)
- * Introduce wildcard characters into generated terms
- * Generate multi-word terms
-
-* Write fuller "javadoc" comments.
-
-* Write generic test suite.
-