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

Re: Extensible Value Testing

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 21 Mar 2005 14:15:45 +0000
Message-ID: <423ED711.4080208@hp.com>
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 GMT

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