Rules (calculated field) engine

Question

I have a fun problem ahead of me.

So, I have built a solution for my company that basically handles unstructured information. It works like this:

A user creates a Task, the Task is in reality just a collection of Tags. These Tags can hold any type of value.

So, for example, if a user wants to create a Task that holds a string (think Title) and two date fields (think Start Date and Due Date), the user can create a template for this, and then create as many Tasks as they want.

So in this case, the user might see a list that looks like this after they have created some Tasks:

Title	Start Date	Due Date
Go to Doctor	2001年01月01日	2001年02月01日
Call boss	2005年01月01日	2005年02月01日

Now, I want to create a ruleset for the user, for example, create some rules to check that "Due Date" is in the future compared to "Start Date".

Since the solution has no idea what data is stored, the possibilities are endless.

I do have a pretty good idea of how to create this ruleset but I would love some input before I start.

The way I figure is to build some rules (in reality some type of calculated field) that the user can apply to the Task. For example, a rule that looks like this: if(InternalFieldA > InternalFieldB) If the check is true, everything is fine, if the check is false, throw an error.

But I'm not sure what the best approach should be.

Any tips, tricks?

• Ben Cottrell: I often see this line of thinking lead into the trap of attempting to design a new DSL/programming language. In case you end up thinking about it, seriously consider using an existing general-purpose language to build complex rule sets as modules in that language (or at least build the DSL as an extension or library for that language) since complex decision-making logic is much easier to write and understand in a real programming language than in database tables or object graphs, not to mention easier to unit test and easier to debug when there's a logic error, etc.
• Doc Brown: Tasks may contain arbitrary fields, but I think your case become much easier if there are a few typed standard fields there, which fit to a lot of tasks. So a task may have a title, an (optional) start date, a due date, a priority and a set of arbitrary tags for further information.

Answer 1

You seem to be making a high level database.

Might I suggest finding a suitable model of logic/algebra that makes sense for your users and build the system on that. Eg Relational Databases are underpinned by Relational Algebra. Hierarchical Databases by the humble Tree.

This provides a wealth of mathematical proofs, and algorithms upon which to build your system (instead of stubbing your toe on each issues).

Once you have picked your model, I highly recommend coming up with a 4GL language for it. EG: SQL for Relational Databases.

This provides:

• a high-level language for your users,
• a convenient serialisation format,
• a specification for your developers to understand what is being asked for.
• a way to employ compile/run time optimisation techniques (a very heavily researched field).
• separation between implementation and request

This in turn should suggest how to solve this constraint issue in an elegant, and functional manner.