Note on XForms 1.1 computation dependency definition. A 'counterexample'.

Dear WG,

Here is a simple and 'intuitively' correct form (derived from a customer 
form) that creates a circular dependency if the definition of 
computational reference (XForms 1.1 sections 7.3) is to be followed. As 
such, it must cause an xforms-compute-exception (XForms 1.1 sections 
4.3.2):

<xforms:model id="test">
        <xforms:instance xmlns="">
                <data>
                        <poll_result yes_count="2" no_count="1" 
wins=""></poll_result>
                </data>
        </xforms:instance>
        <xforms:bind nodeset="poll_result" calculate="concat(choose(@wins 
= 'YES','carried', 'defeated'), ' with ', 100 * @yes_count div (@yes_count 
+ @no_count), '% support')"
                        readonly="false()"><!-- readonly is overriden here 
to allow input (for demonstration only)! --></xforms:bind>
        <xforms:bind nodeset="poll_result/@wins" 
calculate="choose(../@yes_count &gt; ../@no_count, 'YES', 
'NO')"></xforms:bind> 
</xforms:model>

<xforms:output>
        <xforms:label>Proposition poll</xforms:label>
</xforms:output>

<xforms:input ref="poll_result/@yes_count">
        <xforms:label>voted 'yes'</xforms:label>
</xforms:input>

<xforms:input ref="poll_result/@no_count">
        <xforms:label>voted 'no'</xforms:label>
</xforms:input>

<xforms:output ref="poll_result/@wins">
        <xforms:label>prevails: </xforms:label>
</xforms:output>

<xforms:output ref="poll_result">
        <xforms:label>poll result: proposition </xforms:label>
</xforms:output>



1. Ideally, this markup is expected to produce  an 
xforms-compute-exception upon the recalculate that follows any input:
Indeed, the <poll_result> element node value calculated by the first 
<bind> obviously 'depends'  on nodes given by it's @wins, @yes_count and 
@no_count attributes. At the same time, the value of the @wins attribute 
in the second bind 'depends' (according to the XForms 1.1 definition of 
computational reference) not just on the @yes_count and @no_count 
attributes nodes but also on the <poll_result> element node itself by 
virtue of it matching the NodeTest for a parent node! The latter 
dependency seems unnecessary and counterintuitive.

Note, the form's model binding expressions do not contain dynamic 
dependencies and from an author perspective there should be NO circular 
dependencies here either - the XForms 1.1 reference definition produces 
them by making a mere NodeTest matching produce a reference. 

2. Suppose, XForms processor implementation does not strictly follow the 
specification in part of dispatching the 'fatal'  xforms-compute-exception
.  Still, depending on the recalculation algorithm, i.e. when, if and how 
circular dependencies are processed, the 2 last outputs  (bound to 
poll_result and poll_result/@wins ) may produce inconsistent or order 
dependent results. In fact, if an implementation of recalculate  follows 
this ('relaxed') approach and does not show inconsistent results on this 
form, try to modify the form by switching the order of the binds. If this 
altered form still works correctly - the implementation not just ignores 
the xforms-compute-exception but does not follow the XForms 1.1 
specification recalculation algorithm either. 

3. To remedy the problem IBM Forms 4.0 implements different computational 
reference definition whereby a node constitutes a reference only if it's 
[immediate] string content is accessed during the XPath evaluation. 
The NodeTest base definition of references is quite useful (in our 
experience) for optimizing the refresh processing of UI bindings (with 
explicitly allowed dynamic dependencies), especially in the XForms 
containers (group, repeat). However, their usage in the recalculate 
algorithm, arguably, trades the convenience of 'partial' solution to the 
dynamic dependency without rebuild problem for the correctness of the 
case, which actually arose in the field and caused a customer to file a 
high severity bug report.

Could the WG, please, consider an errata statement that addresses the 
issue.

Regards,
Vlad Thakhtenberg.

PS. I would also like to bring to you attention in a separate posting 
another potential issue: a so called 'short-circuiting' in XPath 
implementations which can affect the reference collection in XForms 
implementations and may warrant a note by the XForms specification.