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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

Vlad Trakhtenberg

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.  





poll-result.xhtml (2K) Download Attachment