- From: John Boyer <boyerj@ca.ibm.com>
- Date: Fri, 3 Dec 2010 14:43:23 -0800
- To: Claudius Teodorescu <claud108@yahoo.com>
- Cc: www-forms@w3.org
- Message-ID: <OF7C5E058A.2442F004-ON882577EE.006B695F-882577EE.007CD5F4@ca.ibm.com>
Hi Claudius, Both theoretically and in practice (as far as I know), binds can be nested as deeply as you like. There is no limit other than what a form author can reasonably understand or what an application might reasonably demand. It's the same as asking "how deep can XML elements nest". They can go as deep as you like, but XML trees tend to have very high branching factors (i.e. they're not typically very deep at all). The wiki page you're asking about does contain some additional *suggestions* from me about how we might provide alternative syntax for model item properties. The working group has not agreed to put these in the 1.2 language at this time. For example, the working group might go with a user-defined "custom MIP" feature. Something like this: <bind nodeset="/root"> <property name="signed" type="boolean" context=".." value="blah/blah/blah/dsig:SignatureValue != ''"/> </bind> One provides the name of the new MIP, its type (boolean, string, maybe number, maybe more stuff for XPath 2.0), and its value. Maybe other stuff, like how to combine them if there are multiple occurrences. But with a mechanism like this, then maybe it would be sufficient alternative syntax to use for the currently known MIPs, for example: <bind nodeset="some/node"> <property name="calculate" type="string" context=".." value="blah/blah/blah"/> <property name="relevant" type="boolean" context=".." value="abc = 'xyz'"/> </bind> Perhaps an argument for named MIP elements like calculate and relevant, in addition to property, would be that we could set clever defaults for certain attributes. For example, in my prior suggestion I used the attribute name (value or boolean) to indicate the type of result I wanted. But if 'value' were always used, and instead you had a 'type' attribute as is done for the property tag above, then we could potentially give it a tag-specific default, so that the markup would look like this: <bind nodeset="some/node"> <calculate context=".." value="blah/blah/blah"/> <relevant context=".." value="abc = 'xyz'"/> </bind> The type attribute is not specified on the above calculate and relevant tags because the defaults are set appropriate. Again, neither of the above are yet on the 1.2 plan, but if anything makes it to 1.2, I would guess it would be the property tag and *not* the other tags because this maximizes the benefit to cost ratio. And furthermore, suppose we had the property tag and were debating whether to also add calculate, relevant, etc. Well, frankly, I'd rather see us first solve the issue that you had to add the context attribute to each property. Maybe it is as simple as below: <bind nodeset="some/node"> <property context=".."> <property name="calculate" type="string" value="blah/blah/blah"/> <property name="relevant" type="boolean" value="abc = 'xyz'"/> </property> </bind> Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria 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 From: Claudius Teodorescu <claud108@yahoo.com> To: www-forms@w3.org Date: 12/02/2010 11:32 AM Subject: Re: Nested binds in future versions of XForms spec Hi, I am back with other questions. On the page about unified evaluation context (http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context), one can find the following example: <bind nodeset="node/a"> <constraint context=".." operator="and"> <constraint boolean="b"/> <constraint boolean="c"/> <constraint operator="or"> <constraint boolean="d"/> <constraint boolean="e"/> </constraint> <constraint operator="not" boolean="f"/> </constraint> </bind>. This example shows some nice possibilities as to constraints on data. 1. Is the following syntax correct: <bind nodeset="node/a"> <constraint context=".." operator="and"> <constraint boolean="b"/> <constraint boolean="c"/> <constraint operator="or"> <constraint boolean="d"/> <constraint boolean="e"/> </constraint> <constraint operator="not" boolean="f"/> </constraint> </bind> <bind nodeset="node/a"> <relevant context=".." boolean="b"/> <readonly context=".." boolean="c"/> </bind> <bind nodeset="node/a"> <relevant context=".." value="b"/> </bind>, or should all MIPs grouped as children of a single bind element. I understand that this future approach allows more MIPs to be applies to a given node, which the first example shows, but what about the second example above? 2. Theoretically speaking, how depth can one nest binds? Thank you, Claudius Teodorescu
Received on Friday, 3 December 2010 22:44:07 UTC