- 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 UTC