W3C home > Mailing lists > Public > www-forms@w3.org > December 2010

Re: Nested binds in future versions of XForms spec

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:21 GMT