[OK?] Re: minor technical on 11.2.1 Invocation

Oops, forgot to ask if this adequately addresses your comments. Our
process requires that we track the resolution of comments. (The "[OK?]"
in the subject indicates that I think I have addressed them.) If you
believe that this message resolves this issue, please indicate so in a
reply. If you wish to cater to our tracking system, you can prefix
your reply subject with "[CLOSED]". Thank you for your attention.


On Wed, Jan 25, 2006 at 11:45:30AM -0500, Eric Prud'hommeaux wrote:
> On Thu, Jan 12, 2006 at 09:37:32AM -0800, Fred Zemke wrote:
> > 
> > 11.2.1 Invocation
> > The second bullet says "For functions and operators where the result
> > type is specified as xsd:boolean, the effective boolean value...is
> > calculated".  Quite apart from whether you retain the notion of
> > effective boolean value, this bullet appears to be either incorrectly
> > worded or misplaced.  The issue is whether this bullet item is talking
> > about the arguments or the result.  As worded, it refers to the result
> > type, so it seems to be saying that the effective boolean value of the
> > result is computed.  However, the result itself is not computed until
> > bullet four.  Based on the placement of the bullet, possibly what is
> > meant is that the effective boolean type of the argument(s) is
> > computed.  But in that case, the bullet should not be activated based on
> > the result type.  For example, consider the isIRI function.  The
> > result type is xsd:boolean, but you do not want to compute the effective
> > boolean value of the argument.  On the other hand, consider A || B
> > or A && B.  For these operators, you do want to convert the arguments
> > to effective boolean values.  But this can be decided, not on the
> > basis of the result type, but rather on the basis of the argument type.
> > Probably what you mean is "For each argument whose type is xsd:boolean, the
> > effective boolean value of the argument is computed."
> 
> Following XQuery/XPath's lead, SPARQL does not do implicit EBV
> calculation except on OR, AND, NOT and FILTER
> 
> Section 11 of the current editor's draft has been approved by the work
> group (see [ISS]). The current Filter Evaluation rules [FIL] and the
> EBV rules [EBV] should constrain the definition of EBV to those times
> where a boolean is needed:
> 
> [[ [FIL]
> 11.2 Filter Evaluation
> 
> SPARQL provides a subset of the functions and operators defined by
> XQuery Operator Mapping. XQuery 1.0 section 2.2.3 Expression
> Processing describes the invocation of XPath functions. The following
> rules accommodate the differences in the data and execution models
> between XQuery and SPARQL:
> 
>     ...
>     * Functions invoked with an argument of the wrong type (except
>     xsd:boolean) will produce a type error. Functions requiring an
>     argument of type xsd:boolean are coerced to xsd:boolean using the
>     EBV rules in section 11.2.2 .
> ]]
> 
> 
> [[ [EBV]
> 11.2.2 Effective Boolean Value (EBV)
> 
> The XQuery Effective Boolean Value rules rely on the definition of
> XPath's fn:boolean. The following rules reflect the rules for
> fn:boolean applied to the argument types present in SPARQL Queries:
> 
>     * If the argument is a typed literal with a datatype of
>     xsd:boolean, the EBV is the argument.
>     * If the argument is a plain literal or a typed literal with a
>     datatype of xsd:string, the EBV is false if the operand value has
>     zero length; otherwise the EBV is true.
>     * If the argument is a numeric type or a typed literal with a
>     datatype derived from a numeric type, the EBV is false if the
>     operand value is NaN or is numerically equal to zero; otherwise
>     the EBV is true.
>     * All other arguments produce a type error.
> 
> An EBV of true is represented as a typed literal with a datatype of
> xsd:boolean and a lexical value of "true"; an EBV of false is
> represented with a lexical value of "false".
> 
> [Informative: Effective boolean value is used to calculate the
> arguments to the logical functions logical-and, logical-or, and
> fn:not, as well as evaluate the result of a filter.]
> ]]
> 
> Consistent with the informative note at the end, EBV is only mentioned
> in the evaluation of a FILTER, in logical-or and logical-and. The
> definition leaves room for extension functions to take a boolean
> argument and automatically invoke the EBV rules.
> 
> [ISS] http://www.w3.org/2001/sw/DataAccess/issues#valueTesting
> [FIL] http://www.w3.org/2001/sw/DataAccess/rq23/#evaluation
> [EBV] http://www.w3.org/2001/sw/DataAccess/rq23/#ebv



-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.