Re: Question about MIP childs of binds (XForms 1.2 : Unified evaluation context)

Hi Nick,

We can discuss on the call, as it is actually orthogonal to the issue of 
unified context. This is just something we could do, or not do, while 
we're in the neighborhood, so to speak.

But from the form author perspective, the boolean-from-string() 
interpretation seems better because it directly maps to the *content* of a 
node of type xsd:boolean, and forms are more often about content than 

For example, if I have some node kicking around like this:


using it to control a "guardian" element's relevance *should* be as easy 
as this:

<bind nodeset="... guardian" relevant="isChild"/>

But because *all* MIPs are interpreted as strings, and because of an XPath 
quirk, the above does a dratted node existence test.

This is one of those annoyances where we often have to explain to people 
why their straightforward-looking reasoning does not work.  At some point, 
it isn't them!  And you can tell it's us based on what we have to tell 
them to do:

<bind nodeset="... guardian" relevant="boolean-from-string(isChild)"/>

It would be much better to have the 99% case be the default, i.e. to 
default to boolean-from-string interpretation of the results of relevant, 
readonly and constraint.

For the few cases where you actually do want to do a node existence test, 
I would say the following:

1) the form author is a more complicated person because they are dealing 
with optional content in their schemas, so having to write something more 
in this 1% case is OK

2) the node existence test can be simpler than what you wrote; rather than 
invoking if(), just use boolean(some/node).  This would work because the 
boolean result would be converted to string in order to be valid input to 
boolean-from-string(), and then it would be converted right back to 

In XForms 1.1 and below, we've consumed XPath, which had to pick a default 
way of converting a nodeset to boolean, and it picked the wrong way for 
forms, though perhaps the right way for XSLT.  So this just seems like one 
of those "not a perfect fit" issues that comes from adopting someone 
else's technology.  The ease-of-authoring mandate means it is time to 
smooth out some rough edges. 

Now, you might say that the highest priority is to keep the "simplified 
authoring" syntax simple, and the "canonical" XForms syntax does not have 
to change unless it is hard to convert from simplified to canonical form. 
For example, we could say that this markup:

<div name="guardian" relevant="isChild">
   <input name="name"> ...

implies a canonical form that automatically adds the 
boolean-from-string(), like this:


   <xf:bind nodeset="guardian" relevant="boolean-from-string(isChild)"/>

<group ref="guardian">
   <input ref="name"> ...

Maybe that's good enough, but it does seem to continue to penalize authors 
of canonical XForms.

Best regards,
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

Blog RSS feed: 
02/26/2008 06:01 AM

John Boyer/CanWest/IBM@IBMCA, XForms <>

Question about MIP childs of binds (XForms 1.2 : Unified evaluation 


While working on my action items, and more specific Unified evaluation 
context(1).  I've re-read your e-mail (2) related to this action item. I 
completely agree with most of your remarks. But I'm not convinced by your 
proposal to specify "that the element relevant could 
be defined as automatically applying boolean-from-string to the string 
result", because: 

1) XForms 1.0 and 1.1 define that boolean() is used to convert the node 
set to a boolean for the MIPs 
2) Other w3c specs use the same strategy as XForms 1.0 and 1.1 to come to 
an 'effective boolean' : XPath (see (3) (4) and (5) for places where 
boolean() is used to convert a node set to a boolean), XSLT, ... 
3) When we will use boolean-from-string() instead of boolean() it becomes 
really counter intuitive to check for existence of a node example : 
if(<xpath-expr>, 'true', 'false') 


Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171

Inventive Designers' Email Disclaimer:

Received on Wednesday, 27 February 2008 01:50:45 UTC