Automatic casting of boolean-like-strings in MIPs

In order to reach a conclusion about using boolean-from-string semantics in
MIP attributes to automatically cast strings, numbers, text nodes, or nodes
containing text, we should examine the different results that different
inputs to the two systems may give

Same whether cast or uncast:
(1) Path to a node containing "true" or "1"
(2) true(), or false()
(3) The string "true" or number 1, or output of a function evaluating to
either:  e.g. concat("tr","ue"), or string-length("a")
(4) Path to a node that doesn't exist.

true when uncast, false when cast:
(5) The string "false" or any number other than 1, or output of a function
evaluating to either:  e.g. concat("fal","se"), or string-length("hello")
(6) Path to any other extant node or nodes (e.g. containing "false", or
"foo", or complex content)

So, (1)-(4) are unaffected by the change and therefore, are of no concern.
Further, I doubt that anyone other than the terminally pedantic is likely to
use (5) in the hope of returning a response of true, so that leaves us
discussing what to do about (6).

It is, as some mentioned on the call, quite likely that people are using an
existence test like this to drive forms, so the changing this to return
false, instead of true, would be wrong.

Something I note about boolean-from-string, is that (although more verbosely
defined in the spec) it boils down to being  true for "true" or "1", and
false for any other value.  i.e. "false" is the default return value for
boolean-from-string.  This is contrary to other boolean casts in my
experience, which are false for "false" or "0", and true for any non-zero
value.

Perhaps the problem lies, not with invoking automatic casting in this way,
but with the semantics of the cast.  If boolean-from-string were worded such
that false is returned only for "false", "0" or "", then a different picture
would arise:

If "true" were the non-zero return from boolean-from-string, then (1) to (4)
above would still be the same, whether cast or uncast, but (5) and (6) would
be different:

Same whether cast or uncast:
(6a) Path to any non-empty node containing any value other than "false" or
"0" (e.g. containing "foo", or "bar", or complex content)

true when uncast, false when cast:
(5a) The string "false" or the number 0 , or output of a function evaluating
to either:  e.g. concat("fal","se"), or string-length("")
(6b) Path to a node containing "false" or "0"
(6c) Path to an empty node

With this inversion of the boolean-from-string default return value in
place, all of the nodes that currently counterintuitively return true (i.e.
those where the input appears to be "false"), now return false.

The only troublesome case is 6c.  Although this looks to me like it should
return false, when given as an argument to boolean-from-string,  I feel that
as a MIP, it should be treated as an existence test.

-- 

<http://webbackplane.com/paul-butcher>