Rich (and other information_modelers),

Thanks. I had picked up one or two typos, but your detailed
review is very valuable. I'll apply the changes soon.

My Treetop grammar for the core of CQL is checked-in to SVN
for ActiveFacts, though it needs the current edge (not the Gem)
of Treetop that has my patches in it - and also my Polyglot gem.
Treetop is *magic* at resolving this grammar, which needs a lot
of back-tracking. Such a language was infeasible before the
invention of PEG (packrat) parsers.

You can use bin/read_norma.rb -C to dump a NORMA model in
CQL.

The semantic backend of the CQL parser is still missing, but I'm
making progress on that at the moment. I also have a collaborator
who's interested in working on APRIMO with me, so that should
see some progress too.

I'll probably do a naive Relational Compositor soon, using the
6NF mapping directly, so I can make a start on executing
queries. That'll give a framework for testing a more sophisticated
Compositor.

I also need to make a start on the runtime API. At the moment,
I think that Value Types should be represented using the base
Ruby data types (Strings, etc), perhaps Struct for entities, both
augmented with an extra method for each role, and a "derivation"
or "origin" method to tie back to the query or DDL construct, by
way of reflection. Your thoughts? I need to do a detailed review
of the DotNET 3.5 Entity Framework, which is attempting similar
goals.

I also have a more complicated question regarding queries to
answer. It'll take some work to phrase the question though, so
I'll leave it for now. Basically it's about how to handle query
parameters - whether to provide bindings (values) for any query
variable, or to write each query parameter using a transient fact
type, for which a transient fact pool (population) is invoked. The
latter is easier, supports generation of stored procedures, and
matches the Rails session concept, but is less flexible. If that
question makes sense to you without further explanation, you
might share your thoughts.

> Nits:
> ... specification, design and implementation.
> design,

Why is this correct (a comma before "and"), when the following
isn't? Is it because it's a list?

> ... so evolution is costly, and the database ...
> costly

Clifford Heath.