W3C home > Mailing lists > Public > public-forms@w3.org > March 2008

Re: About binds and variables and the processing model

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 27 Mar 2008 18:12:34 -0700
Message-Id: <ED060605-5219-4091-9344-B46ABCE20A4B@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>


I am glad that another pair of eyes finds this easy as well :-) It  
looks like we are on track.


On Mar 27, 2008, at 4:07 PM, John Boyer wrote:

> 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/

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Friday, 28 March 2008 01:19:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:56 UTC