- 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