Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | *VarRef* | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412