- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 27 Mar 2008 18:12:34 -0700
- To: "Forms WG (new)" <public-forms@w3.org>
John, I am glad that another pair of eyes finds this easy as well :-) It looks like we are on track. -Erik 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 http://www.orbeon.com/
Received on Friday, 28 March 2008 01:19:09 UTC