[
https://issues.apache.org/jira/browse/DAFFODIL-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Beckerle updated DAFFODIL-1513:
------------------------------------
Priority: Minor (was: Major)
> improve diagnostic for true vs. fn:true() boolean
> -------------------------------------------------
>
> Key: DAFFODIL-1513
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1513
> Project: Daffodil
> Issue Type: Bug
> Components: Diagnostics, Front End, Middle "End", Usability
> Reporter: Mike Beckerle
> Priority: Minor
>
> 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:
> {code}
> <element name="myBoolean" default="true" ..../>
> <dfdl:defineVariable name="myBooleanVar" defaultValue="{ fn:true() }" />
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
