This is an ambiguity inherent to the DRL language. This happens because the parser has no way of knowing if the (...) following the expression belong to the expression (i.e., is a method call, where you forgot the "," between parameters) or if it is not part of the expression. So, we arbitrarily decided that the parser will always consider the () in this case as part of the expression, and if it is not a valid syntax, it will raise an error. You found one way of breaking the ambiguity by adding () on getAddresses, but you could also do: ( Address( ) from $person.addresses ) or add a ; at the end of the expression: Address( ) from $person.addresses; It is not a bug, as it is an ambiguity inherent to the language, not the implementation, but I guess we could have better documentation on that. Just for the curious, it is the same kind of ambiguity present on java/c++ parsers when you have nested "if/else" without blocks {}. Ex: if (...) if( ... ) ...; else ...; Does the else above belong to the first or second "if"? The parser has no way to know that, so they arbitrarily decided that in java/c++ that says the else belongs to the closest "if" and my identation above is misleading... Edson 2011/1/26 Evert Penninckx <evert.penninckx(a)gmail.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com