- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Tue, 23 Feb 2010 16:50:48 +0000
- 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 UTC