- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 21 Mar 2005 14:15:45 +0000
- To: Geoff Chappell <geoff@sover.net>
- CC: public-rdf-dawg-comments@w3.org
Geoff Chappell wrote:
> Discusses extension functions, section 11.3 says:
>
> "A function is named by URIRef in a QName form, and returns a boolean value.
> "true" means accept; "false" means reject this solution."
>
>
> That seems at odds with the way the return values of other functions are
> interpreted. For example:
>
> Graph:
> Ex:Fido a ex:Dog.
>
> Query:
> Select ?x where {?x a ex:Dog. FILTER xs:string(1 > 2)}
This area has be "clarified". The value extension functions are now just
functions returning a value (hence making casting and functions the same thing).
That value can be used in other expressions and it is the value of the top
level expression that determines whether to accept or reject a solutions
according to the F&O boolean effective value rules.
Andy
>
> By my reading on the latest draft, this query would return a value since
> it's the effective boolean value of the _whole_ constraint clause that
> determines whether or not a solution is accepted (and the xsd:string
> "false", the result of coercing the value of the comparison into a string,
> is non-empty so is considered TRUE.)
>
> But section 11.3 implies that:
>
> Graph:
> Ex:Fido a ex:Dog.
>
> Query:
> Select ?x where {?x a ex:Dog. FILTER xs:string(my:even(1))}
>
> would not return a value (since my:even has returned false meaning reject
> the solution).
>
> Am I misunderstanding something? Is that the intent? And if not, why
> restrict extension functions to returning boolean values?
>
> -Geoff Chappell
>
>
Received on Monday, 21 March 2005 14:49:02 UTC