DSLs have proven useful.

They are also a powerful way to let users create their own languages (which may be natural language based).

In future, we can have some "built in" natural language constructs for people to build on (or use out of the box).

To do these enhancements, we need some key features:

• Grammar must be more of a true grammar, ie must be able to specify valid types/values/other DSL expressions (nesting of grammar)

• Grammar should cover all of the rule (including the if/then structure, and attributes if needed).

• Need to have special handling of "list" items (using "dashes" on each line, as well as comma seperated lists) for data entry

• Bound variables need to be "specially treated" - so when a grammar knows it is dealing with valid

• Be able to have built-in expressions (in english for example) that users supplement or replace

• Field handling - field names and valid operators on a fact-column should be automatically inferred (users can override them in a grammar). eg when you choose "person" then the grammar will know what valid fields there are.

This is kind of like defining an ontology for facts (a very simple one) - the exact format of the DSL grammar is not defined at this time. Tooling is important, so the knowledge that both IDE and web tooling needs to be able to provide a user interface with content assistance constraints things somewhat.

In terms of implementation, rules using the above grammar can be persisted as an object graph (say using XStream) - with a UI providing editing capability. However, an ideal approach is to generate an antlr grammar dynamically from the user grammar (or perhaps use JParsec) which can then recognise plan text, and also be used to drive the text editor IDE UI. Plain text is good.

The DSLs can output DRL for rule engine consumption (or perhaps go direct to AST - many people prefer the DRL option though - for hardcore technical debugging when needed).

WHY:

• i18n is important, no one will be happy with anglo centric approach.

• templating proven successful

DOWNSIDES:

• Tooling: can use antlr - but for web based, not so easy (or perhaps just use meta model if possible).

• User view of grammar getting more complicated.

EXAMPLE GRAMMAR:

[if]My favourite animal is {y<animal>} = ... 

(this uses the "animal" scope below, which there may be multiple options or just one)

[animal]a {<string>color} elephant=...

[if]My favourite foods are {a <xyz> *} = ...

-- in this case, means a comma seperated list (of whatever "xyz" actually is !), or "-" and newline seperated as you can do currently. XYZ is defined somewhere else in the grammar of course (or built in).

[if]There is at least one Person with {<Person.field-constraints>}=...

-- this means that it will know that it can accept a list of field constraints like "age is less then or equal to '42'" and so on. It will know from the fields of the Person fact what valid operators are. Of course, we can have some built in sentences similar to the above that are generic to any fact type.