Re: function library summary and issues

On Nov 24, 2010, at 1:12 PM, Steve Harris wrote:

> On 2010-11-24, at 15:20, Andy Seaborne wrote:
> 
>> Practicality suggests simple literals are important.
>> We can overlay on XSD F&O so for example:
>> 
>> CONCAT("a"^^xsd:string, "b"^^xsd:string) -> "ab"^^xsd:string
>> CONCAT("a", "b") -> "ab"
>> CONCAT("a"^^xsd:string, "b") -> "ab"^^xsd:string (?? choice point)

I think I'd want this to produce a simple literal, but as Steve says, without experience here it's hard to know.

>> CONCAT("a"@en, "b"@fr) -> error? (choice point [*])
>> CONCAT(str("a"@en), str("b"@fr)) -> "ab"
>> 
>> [*] lang tag support in comparisons etc is not required by base SPARQL so it's an error. The question is whether to provide guidance to implementations that wish to provide it.
> 
> Re. [*], for impl's which choose to implement it, I would favour "ab" as a result. We use language tags quite a bit, and though we haven't been able to concatenate them up to now, I would like/expect CONCAT("a"@en, "b"@fr) -> "ab". Less straightforward is CONCAT("a"@en", "b"@en), should that be "ab"@en, or "ab". Dropping the lang tag in all cases seems fine to me.

I also would prefer CONCAT("a"@en, "b"@fr) -> "ab". I have no preference on whether concat of two literals with the same language tag should yield a language tagged literal.

> What about CONCAT("1"^^xsd:integer, "2"^^xsd:integer), following F&O strictly it would be "12"^^xsd:string I believe.

I'm a bit freaked out that this is going to cause confusion if + is also being used for string concat (assuming we follow the strawpoll support for overloading +). + would yield addition over xsd:integers, while the CONCAT() syntax would yield "12" with xsd:integers. Something doesn't seem right about that.

>> Whether the choice is by new URIs for the functions or punning on XSD F&O is part of this decision point.
>> 
>> Suggestion:
>> 1/ Keywords as below.  No dateTime functions.

I'm mostly indifferent to whether these functions are available as keywords, but if they are I support not having keywords for the dateTime functions.

>> 2/ sparqlfn: URIs for all function (our namespace and URIs)

Yes.

>> 3/ Definition as XSD F&O except work on simple literals as noted.
>> 4/ Documentation reference XSD F&O for each function.

I don't have strong feelings one way or another about the xsd:string stuff that's described in F&O. I just want to see support for simple literals with the string functions.

>>       7.4.3 fn:substring
>> Two forms /2 and /3
>> SUBSTRING
>> Note it's one-based counting and it's (index, length) unlike some languages.

One-based? Ick! :)

>> 	3. fn:error
>> ERROR()
>> ERROR(string)

Has this been discussed before? I don't recall what this is meant to do.

.greg

Received on Wednesday, 24 November 2010 18:41:08 UTC