Folk on the information_modeling list (and others).

Just a quick update so you know what I've been doing with
ActiveFacts recently. When I last wrote, I was nearly done
with defining the CQL data definition language. I can dump
any model (including one imported from NORMA) into CQL.
Work on CQL is continuing - I still have to make some final
decisions on which of several syntaxes to use for external
constraints. You can read the examples with the CQL here:
<http://activefacts.rubyforge.org/svn/examples/>. But in the
meantime...

Metamodel:

I've completed a metamodel in NORMA, and I can dump that
to CQL. You can read the metamodel in PDF, PNG images, or
CQL here:

PDF: <http://activefacts.rubyforge.org/svn/examples/pdf/Metamodel>
PNG: <http://activefacts.rubyforge.org/svn/examples/images/Metamodel>
CQL: <http://activefacts.rubyforge.org/svn/examples/CQL/Metamodel.cql>

Note that you'll need to save the PDF and PNG files before
opening them. A text file listing my outstanding issues is posted here:
<http://activefacts.rubyforge.org/svn/docs/MetamodelIssues.txt>.
Comments and review is welcome.

Runtime API:

Now, my interchanges with Matthew Wilson have inspired me
to jump ahead to start defining the Ruby runtime API to be
used in programming an ActiveFacts application. I wrote a
preliminary design document which any Ruby people especially
are welcome to comment on; it might not make much sense to
others. I've also explored and solved issues with the dynamic
programming required to implement it. The document is here:
<http://activefacts.rubyforge.org/svn/docs/API.txt>

As the runtime implementation progresses, I'll also construct a
generator, which can dump any model as a runtime API definition.
In fact I've hand-crafted an instance of a runtime API for the
CompanyDirector model, for use in checking the API.

New base API?

This raises an interesting possibility. Since I have a metamodel,
and I will have an API generator for any model, I should be able
to dump the metamodel as an API, and use that as a new base
API to replace my hand-crafted one. This is likely to resolve some
consistency issues with the old API, and is also a very real test
for the ease of programming with the new API. In the fullness of
time, it'll also provide relational persistence, so I can use it in my
Rails applications, and even APRIMO.

Upcoming work:

Once I have the runtime API roughed-out and a generator for it,
I'll finish both the external constraint syntax and the backend of
the CQL parser, potentially making it work to the new base API
generated from the metamodel.

The metamodel doesn't support queries yet, and the base API
won't yet enforce constraints, so those will be the next goals
before working on adding the relational persistence layer. At the
moment I think I'll use the Sequel Ruby module to access the
various database engines.

So that's about the size of things. The project is proceeding well,
and I expect to have some useful artefacts pretty soon now.

Clifford Heath, Data Constellation.