Re: About binds and variables and the processing model

Hi Erik,

I think this is excellent.  Good job to you and your team at work!

So, to summarize, the point is that we don't have to come up with an 
"order" to evaluate the binds if we:

1) Make the limitation that the variables are *not* available to nodeset 
expressions of the bind element (this was the big scary one anyway)

2) Slightly adjust the processing model of rebuild so that all bind 
nodesets are resolved first, then as a second pass all MIPs are done.

I agree that it sounds very easy.

Also, we have to tweak our working definition of the variables (as we also 
found on the telecon) so that we get the union of nodeset from binds when 
the context node is associated with a containing ancestor of the 
identified bind.

The more I think about it, the less I like doing this by adjusting the ID 
reference mechanism in 4.7 because that is explaining how an IDREF selects 
a run-time object in a general sense.  We can define a "variable 
reference" as indicating the union of nodesets from one or more run-time 
bind objects selected from the minimal subtree of run-time objects 
obtained by selecting the closest ancestor bind associated with the 
context node.

Either way, it looks like we have all the pieces in place.  I will send a 
new summarization email shortly.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
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
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
03/26/2008 05:27 PM

To
public-xforms@w3.org
cc

Subject
About binds and variables and the processing model







All,

I think that we had a good conversation this morning about the design
of the simplified syntax. Following-up on this, we had a little
brainstorming here at work about the question of variables in binds.

Consider this example:

<xforms:bind nodeset=".">
    <xforms:bind id="subtotal" nodeset="subtotal" 
calculate="sum($lineTotal)"/>
    <xforms:bind nodeset="row">
        <xforms:bind id="lineTotal" nodeset="lineTotal" 
calculate="$unitCost * $qty"/>
        <xforms:bind id="unitCost" nodeset="unitCost"/>
        <xforms:bind id="qty" nodeset="qty"/>
    </xforms:bind>
</xforms:bind>

This is clearly a case in line with what we were talking about this
morning where one bind refers, by variable, to a bind declared by id
further down.

I have intentionally reverted the order of all references to make the
problem all the more visible.

But it seems to me that if, for a start, we do not allow using
variables within xforms:bind/@nodeset attibute, the only constraint is
that when evaluating attributes such as @calculate, etc., the bind
nodesets have already been evaluated.

So you could just do a first pass evaluating the bind nodesets. This
allows you to declare all the variables which are in scope. Then you
are back to the current case of the dependency algorithm. Sounds very
easy to me.

Or am I missing something?

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/