W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2006

Re: minor technical on 11.2.1 Invocation

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 25 Jan 2006 11:45:30 -0500
To: Fred Zemke <fred.zemke@oracle.com>
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <20060125164530.GY17752@w3.org>
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.

Received on Wednesday, 25 January 2006 16:45:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT