Yet on the other hand, if/when it would be possible to use column binding in field constraints, this functionality will be possible to achieve like this, ie, rewrite this piece: Record (fieldAsString matches "[xyz]" or fieldAsInt > 1, $myOtherField : myOtherField) Record ($field : field, fieldAsString matches "[xyz]" or fieldAsInt > 1, myOtherField == $myOtherField) Record (field == $field) as $r: ( $r1: ( Record (fieldAsString matches "[xyz]") or Record (fieldAsInt > 1) ) $r2: ( Record (fieldAsString matches "[xyz]", myOtherField == $r1.myOtherField) or Record (fieldAsInt > 1, myOtherField == $r1.myOtherField) ) Record (field == $r2.field) ) More verbose, but I think it should work the same way.... _____ From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Olenin, Vladimir (MOH) Sent: 27 March 2007 11:02 To: Rules Users List Subject: [rules-users] followup - 'or' for different field constraints ... the only thing that would not be allowed is to do the binding on the this 'connective constraint', since it would make sense. Eg, Record ($invalidBinding : fieldAsString matches "[zxc]" or fieldAsInt > 0) ) , since it's kind of 'views' for the 'field' variable, while this one will work: Record ($correctBidning : field, fieldAsString matches "[zxc]" or fieldAsInt > 0) ), ie you need to bind the 'original' field, NOT the views. To think of this, it would actually be need to the <field>AsString, <field>AsInt, etc getters to be autogenerated.... Or even better - do that behind the scene depending on the context, if there is no ambiguity involved... Vlad