So this is a wierd thing.

XPath doesn't have "true" or "false", but rather these annoying functions that return those boolean values, so fn:true() and fn:false() are the way you create an expression with constant value true or false. I find this strange personally. But DFDL expressions follow XPath in this convention.

Problematic is that as the default value in a XML schema, however, true and false ARE the boolean values.

Hence, this inconsistency:

<element name="myBoolean" default="true" ..../>

<dfdl:defineVariable name="myBooleanVar" defaultValue="{ fn:true() }" />

I find this most annoying. Why XPath left out literal constants for true/false I don't know, but there it is.

Daffodil should issue a diagnostic that specifically looks at expressions for true/false and specifically suggests need for fn:true() or fn:false() calls instead.

(Right now you get a diagnostic about true or false not being a valid path step..... which is accurate, but people are very unlikely to have actual elements named true or false so the word false is unlikely to mean the same thing as "./false". Far more likely it's a mistake where fn:false() is what was intended.