Re: LC: Problems with Binding Expressions changing evaluation context of other attributes (PR#28)

John,

we agree that we need a simpler version, but that it is in scope of XForms 1.2,
so this issue is deferred.

Regards,
Ulrich Nicolas Lissé

For the Forms WG

> Once a binding expression on an element is evaluated, XForms uses the
> identified node as the context node for other attributes on the same
> element.
> 
> One example where that creates a limitation is given in the following last
> call comment:
> http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html
> 
> But other cases exist.  For example, if an instance has three instance
> nodes as follows:
> 
> <data>
>    <a>2</a>
>    <b>2</b>
>    <c>4</c>
> </data>
> 
> then one must write the following to put the result of a+b into c:
> 
> <bind nodeset="c" calculate="../a + ../b"/>
> 
> The excessive dots are a nuisance, and when the novice writes what is
> reasonable to expect-- calculate="a+b"-- the result is NaN.  This is
> because the calculate is interpreted relative to the node c, and the node
> c has no child elements named a and b.  The dots are needed to traverse up
> to the parent of c so that its siblings may be obtained.
> 
> The problem becomes more acute in larger formulae, which occur often in
> constraints.
> 
> It should be noted that fixing this problem might mean that the above bind
> would no longer be equal to the following nested bind (because the outer
> bind sets the evaluation context for the inner bind):
> 
> <bind nodeset="c">
>      <bind calculate="../a + ../b"/>
> </bind>
> 
> It is a decision point as to whether preserving that equivalence between
> the nested and non-nested bind is important.  If not, then the nested bind
> would give another way to get the old 1.0 behavior back for those who want
> it.  If so, then that might simply affect how the problem is solved.
> 
> Needless to say, it would be too problematic for the existing XForms
> community to do away with the current method of determining the evaluation
> context for attributes like @calculate on bind or @value on setvalue.  So
> we would need some kind of attribute for turning on a different method.
> This attribute could *default* to the new method when the XForms model
> @version attribute is set to 1.1.
> 
> Perhaps something like <model unifiedcontext="false" version="1.1" ...>
> would suffice to keep the old context evaluation in 1.0, and one could
> optionally write unifiedcontext="true" to make the change to having all
> attributes of an element use the same eval context.  And,
> unifiedcontext="true" could be the default for version="1.1" XForms.
> 
> I don't have a good solution yet for how this could be done if the nested
> bind and non-nested bind cases above must remain equivalent, but last call
> rules say my proposal does not have to be complete, and in this case, I
> call out this equivalence as a decision point, so we don't have to solve
> it if the answer is no.
> 
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 
>

Received on Friday, 14 September 2007 08:59:08 UTC