It's not clear from your description, what the "keyword" substitution should achieve. Usually, class and field names should be chosen so that they convey a meaning to the rule author. Note that the DSL translator lets you mix DRL code lines with DSLR lines. -W On 09/08/2012, san_drools <pathasantosh(a)yahoo.co.in&gt; wrote:

OK, so you use this as a DSL definition. Where is the problem? -W On 9 August 2012 16:22, san_drools <pathasantosh(a)yahoo.co.in&gt; wrote:

The basic idea of the DSL implementation in Drools is to use phrases (and not just single keywords) with a translation into DRL. These phrases can have parameters. On 9 August 2012 19:08, san_drools <pathasantosh(a)yahoo.co.in&gt; wrote: You can use "$ContactNum" from the DRL translation. It's not "hidden". Here you might use a parameter. Your DSL phrase can be [when] PersonMobileContact with {X} ={X} ($ContactNum : contactNumber && contacttype == "mobile") and you can write PersonMobileContact with Object1 PersonMobileContact with Object2 -W

On 10/08/2012, san_drools <pathasantosh(a)yahoo.co.in&gt; wrote: Consider this DSL definition: [when][]ThereIsProgramHistoryData = ProgramHistory () [when][]- where {VarName} is {AttributeName} and is {operator} {value}= {VarName}: {AttributeName} {operator} {value} So you can write in DSLR ThereIsProgramHistoryData - where lpy is levelPriorYear and is greater than 0 Note that the author can choose the name ("lpy") with which the field ("levelPriorYear") can be referred to in subsequent conditions. You can add more DSL phrases, or raw DRL (using '>' as the first character): ThereIsProgramHistoryData - where lpy is levelPriorYear and is greater than 0 or you can even use DRL without the '>' provided you add this *as the last definition* to your DSL: [condition][] {anything} = {anything} ThereIsProgramHistoryData - where lpy is levelPriorYear and is greater than 0 eval( lpy < 1000 ) This is what happens anyway. To see the result, add this as the first line to your DSL definitions: #/ result I think that's clear, by now? Distinguish DSLR and DRL. DSLR is where you write rules with phrases you define in an DSL definition, and this is translated into DRL. DRL is translated into the (internal) representation of rules for building the Knowledge Base. If you write DRL, there's no translation before the one from DRL to "internal", so you cannot use anything that's not in the DRL syntax. What you write doesn't make sense to me. A "keyword" is translated into a chunk of text anywhere, a DSL definition with "when" represents a conditional element or constraint in the "when" part, and a DSL definition with "then" expands into a statement in the "then" part. Thus, a "keyword" can be used to represent any piece of text. Make sure to read the documentation. Experiment, using "#/ result" and see what you get. -W

If the values are dynamic and the Fact/Field static for a keyword you could consider using a Template or Decision Table, where for example a single column represents a Fact/Field and the user simply provides the values. I am surprised to read you found DSL had to be defined for every Condition or Action. This is certainly not the case in my experience. If you meant you had to define a DSL for every Fact/Field combination you require this is to be expected. Otherwise, "yes" this can only be achieved by changing the code base. With kind regards, Mike sent on the move On 9 Aug 2012 13:59, "san_drools" <pathasantosh(a)yahoo.co.in&gt; wrote: