Re: bind() function

Hi all,

We've had the discussion numerous times that the potential challenges with 
this function are much greater than just circular dependencies that the 
processor can detect, as Uli's email suggests.

A key issue would be determining where the function actually gives you a 
benefit, and constraining its use to those use cases by generating a 
compute or binding exception if it is invoked from an unsupported 

If you call the bind() function from the ref (or legacy nodeset) of a bind 
element, then you introduce a dependencies problem within rebuild, for 
which XForms processors are not equipped.

Calling bind() from MIP expressions seemed like it caused a fair bit less 
of a challenge. 

What happens, though, if the bind() refers to an inner bind?  Seems that a 
set of rules similar to the ID dereferencing we do for repeat would be 

The use case of the day, however, was calling bind() from a repeat's 
binding.  The challenge there is that the result of a bind is updated on 
the schedule for model binding expressions, not UI binding expressions, UI 
bindings are expected to be more automatic in their responsiveness to data 
changes because they are "leaf" expressions, i.e. nothing refers to them. 
Some analysis must be done (or recovered) to determine whether (or what) 
strange, unexpected behaviors may result from repeat bindings not updating 
in the same way as those which use direct expressions.

A particularly interesting capability arises if an inner repeat could 
refer to an inner bind, but it certainly requires specification.

John M. Boyer, Ph.D.
IBM Distinguished Engineer & IBM Master Inventor
@johnboyerphd |

From:   Erik Bruchez <>
To:, "" 
Date:   02/07/2013 03:31 PM
Subject:        bind() function
Sent by:


We had decide to include the bind() function but there was no related
action item. See:

I suggest we do include it.


Received on Tuesday, 2 July 2013 23:21:20 UTC