LC: Problems with Binding Expressions changing evaluation context of other attributes

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