W3C home > Mailing lists > Public > public-forms@w3.org > November 2008

Re: boolean-from-string() and XPath 2.0

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Mon, 17 Nov 2008 16:26:08 -0800
Message-Id: <563732BC-06D2-4FB2-AE65-3680097A4696@orbeon.com>
To: Forms WG <public-forms@w3.org>

> Can someone point out where in the XPath 2.0 spec does it say that a  
> set of items (e.g. a nodeset) can evaluate to false if the set of  
> items contains one node whose content is falsey?

At first glance, I don't think there is such a thing. There are two  
notions in XPath 2.0:

* Constructor or cast for xs:boolean type (same logic)
* Effective boolean value, which is about like the XPath 1.0 boolean()  
function

> In [1], the working group decided that future versions of XForms  
> would allow boolean MIPs to "treat a false string as false".
>
> [1] http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0025/2008-09-10.html#resolution1
>
> I would like to better understand, though, how this actually fixes  
> the intended problem.  I think that the working group is saying that  
> the result of the MIP is first converted to string, and then the  
> string is converted to boolean, except that the *string* value of  
> "false" is treated as a boolean false.
>
> If we do not assume that the MIP result is converted to string, then  
> the resolution [1] does not fix the problem at hand, which is that I  
> want to have a data node like this:
>
> <isManager>false<isManager>
>
> and I want to have a MIP like this:
>
> relevant="isManager"
>
> The node isManager exists, regardless of its value, and so direct  
> application of the boolean function produces a result of true just  
> based on the existence of the node.
>
> But if the MIP is converted to string before being handled as  
> described in [1], then the above MIP works the way I expect.
>
> Yet, the problem we have is that if the above is accurate, then  
> we've really just come up with another way of saying that we apply  
> boolean-from-string() to the MIP.  And in that case, I think it is  
> better to describe it that way because then we have consistency with  
> how I might describe the negation case.
>
> For example, suppose instead of using relevance to restrict access  
> to some data, I use readonly.  I would be inclined to write this:
>
> readonly="not(isManager)"
>
> But we know that won't work, and we will have to explain why not.   
> When we do, the fix will be to write this:
>
> readonly="not(boolean-from-string(isManager))"

I am only 40% convinced that we should do any of this, because to be  
more explicit you can also write:

   readonly="isManager = 'false'"
   readonly="isManager = 'true'"
   readonly="not( isManager ='true')"

etc. This has the merit of clarity. Yes of course the boolean could  
also be "1" or "yes", which is annoying. But usually documents  
standardize on one of those.

In addition there are those cases where you want to test on existence,  
although with XPath 2.0 you can use the explicit:

   readonly="exists(isManager)"

This said, I thought the idea was to follow the logic of the XPath 2.0  
xs:boolean() constructor instead.

xs:boolean($arg as xs:anyAtomicType?) constructor expects zero or one  
atomic value. If the parameter passed is, say, an element, it is  
atomized, e.g. converted to an atomic type. Otherwise, the typed value  
of the node is obtained. In a DOM without type annotations (most  
XForms implementations at this point I imagine), the typed value is  
the same as the string value. Then that typed value is converted to an  
xs:boolean type as per the XML Schema part 2 logic.

So my understanding is as follows:

<isManager>true</isManager> -> xs:boolean(isManager) -> true()
<isManager>false</isManager> -> xs:boolean(isManager) -> false()
<isManager>1</isManager> -> xs:boolean(isManager) -> true()
<isManager>0</isManager> -> xs:boolean(isManager) -> false()
<isManager></isManager> -> xs:boolean(isManager) -> false()
<isManager>dummy</isManager> -> xs:boolean(isManager) -> false()

etc.

Passing more than one elements will fail with xs:boolean(), so if we  
go this route we should apply the first-node rule I suppose, or decide  
to throw an error if more than one node is available.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Tuesday, 18 November 2008 00:26:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:49 UTC