Several reasons.
- I started this well before SBVR was released, to provide a textual interchange format for ORM2 models.
- I also began with the intention of executing CQL as code, while SBVR makes a principle of avoiding such pragmatic considerations, choosing instead to focus on defining rules for people to interpret.
- SBVR allows declaration of rules that cannot easily be automated. CQL so far only incorporates automatable declarations.
- CQL includes an integrated query language (fact derivation language) that is more powerful than SQL and much more readable. This solves the problem of how to define derived fact types, and offers the prospect that SQL may become redundant. The implementation of converting CQL queries to CQL is not yet done, but much of the groundwork is complete.
- The SBVR Structured English is, like CQL, quite difficult to parse using established compiler generators, but SVBR is much harder.
Neither language is context free, and both support open vocabulary, so parsing requires unlimited lookahead (or backtracking, if you see it that way). Using the most recent tools that implement packrat (or PEG) parsers, such as the Treetop parser generator for Ruby of which I'm a co-developer, makes this backtracking possible to implement in a reasonably efficient way, but I still wasn't sure that SBVR's S.E. was feasible.
An example in CQL, if I have the concepts Person and Location defined, I can say:
Person was born at at most one Location;
Notice that the word "at" has two uses here, one in the key phrase "at most one", and one as a linking word in the fact type reading. The only alternative to this would be to force the two declarations (a fact type and the associated uniqueness constraint) into two separate statements, and use a traditional computer-speak style keyword introducer to decide what type of statement is being processed; this results in the kind of un-natural language that has always shut out business users from the modeling process.
In an SBVR tool or nORMa, colour can be used to highlight the existence of extra-textual syntactic elements, but this departs from my goal of representing models as plain text. The extra elements in nORMa's fact type readings are required to be able to parse them. As it is, my nORMa import tool may emit CQL that cannot be parsed, for example if a concept name is used in a reading as a normal linking word. I'm working to improve recognition of these cases, but they can only be fixed by modifying the original model.
CQL also has the ability to load alternate language modules; the part of the parser that recognises key words and phrases in English is the first of many; it can easily be replaced with one that does the same in Italian or Japanese. So when I say CQL is "structured English", it could be any structured natural language for which the appropriate language adapter module has been written, whether the language uses leading or trailing adjectives. The module for English is only 70 lines of code.
In the same vein, it would be possible with some further work to build an SVBR language subset, merely by defining the appropriate language rules, but re-using all the back-end infrastructure and generators. If someone wants to attempt this, please contact me. As mentioned, I expect to produce commercial software as well as retaining an open source tool, so consider your contributions in that light. I have too much invested to produce everything for free.