W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > March 2005

Extensible Value Testing

From: Geoff Chappell <geoff@sover.net>
Date: Sat, 19 Mar 2005 15:05:36 -0500
To: <public-rdf-dawg-comments@w3.org>
Message-ID: <008001c52cbf$0435d660$6401a8c0@gsclaptop>

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:

	Ex:Fido a ex:Dog.

	Select ?x where {?x a ex:Dog. FILTER xs:string(1 > 2)}

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:

	Ex:Fido a ex:Dog.

	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 Saturday, 19 March 2005 20:05:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:20 UTC