W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: [TF-LIB] Finalizing built-ins

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Tue, 23 Feb 2010 16:50:48 +0000
Message-ID: <4B840768.2070007@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


On 23/02/2010 1:33 PM, Steve Harris wrote:
> Prefer STRDT(?str, ?dt) and STRLANG(?str, ?lang) or something similar,
> for consistency. Agreed that making this polymorphic is maybe not a good
> idea. No strong feelings though.

STR* are OK although it's not a string, it's literal (not a plain 
literal or xsd:string).

LIT_DT
LIT_LANG

LITDT
LITLANG

LeeF suggests:

TYPED_LITERAL
LANG_LITERAL / PLAIN_LITERAL

STRDT is OK, although the fact it is syntax for part of a general case 
(which I have had a request for) of the dynamic call.

Currently, I've put STRDT / STRLANG into the grammar pending consensus 
on this in order to make some progress.

 > I can imagine this playing havoc with peoples extension function
 > implementations, and security models.

Not sure I quite follow.  The only new issue, if a system wants to allow 
the feature anyway, here is a change from from static to dynamic 
resolution.  It won't parse under SPARQL 1.0.

A query processor (QP) can just reject a query with a dynamic call 
(static parse time check).

The QP has to bind the function name to the action for 1.0 custom 
functions anyway (static check).  A QP with a whitelist of acceptable 
functions (hash table) would allow some dynamic calls if the QP wants to 
allow any at all.

It does not affect optimization possibilities for the static case of an 
explicitly named custom function.

It's not loading code based on the data nor reaching outside the query 
processor onto the wild web.

	Andy
Received on Tuesday, 23 February 2010 16:51:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT