Re: function library summary and issues

On 2010-11-24, at 15:20, Andy Seaborne wrote:

> We are making slow progress on this.  This message is to put a more concrete proposal on the table for further WG modification, it's based on what I have heard/seen so far but I may well have missed something.
> 
> Decision point 1:
> Is the list below agreed?
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0188.html
> 
> Decision point 2:
> Whether to add keywords or whether to have only URIs.
> Possible keywords below.
> 
> Decision point 3:
> What URIs?
> I'm assuming there will be URIs for all functions in SPARQL. We need sparqlfn: for the ones we have from SPARQL 1.0 and adding for SPARQL 1.1 anyway (e.g. IRI())
> 
> Decision point 3:
> What to do about xsd:string vs simple literal?
> 
> 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)
>  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.

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

A design where CONCAT always returns an xsd:string is probably also fine, without having used it significantly it's hard to have a clear preference.

- Steve

> 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.
> 2/ sparqlfn: URIs for all function (our namespace and URIs)
> 3/ Definition as XSD F&O except work on simple literals as noted.
> 4/ Documentation reference XSD F&O for each function.
> 
> I am not particularly fond is this way forward nor strongly advocating it.  It's a concrete proposal to move the discussion to a conclusion, I hope.
> 
> 	Andy
> 
> 
> 
> Numeric functions:
> 
>        6.4.1 fn:abs
> ABS
>        6.4.2 fn:ceiling
> CEIL
>        6.4.3 fn:floor
> FLOOR
>        6.4.4 fn:round
> ROUND
>        6.4.5 fn:round-half-to-even
> ??
> Note precision argument.
> Drop?
> See discussion at:
> http://www.w3.org/TR/xpath-functions/#func-round-half-to-even
> 
> String functions:
> 
>        7.3.2 fn:compare
> ? Not needed as a keyword.
>        7.4.1 fn:concat
> CONCAT
>        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.
> 
>        7.4.4 fn:string-length
> LENGTH
>        7.4.7 fn:upper-case
> UCASE
>        7.4.8 fn:lower-case
> LCASE
>        7.4.10 fn:encode-for-uri
> ENCODE
> Note it's ENCODE(string) -> string
> 
>        7.5.1 fn:contains     (collation form optional)
> CONTAINS
> No collation form as required SPARQL function.
> 
>        7.5.2 fn:starts-with
> STARTS
>        7.5.3 fn:ends-with
> ENDS
> 
> DateTime functions:
> ? Drop
> ? Or what naming
> 
>        10.4.6 op:dateTime-equal
>        10.4.7 op:dateTime-less-than
>        10.4.8 op:dateTime-greater-than
>        10.5.7 fn:year-from-dateTime
>        10.5.8 fn:month-from-dateTime
>        10.5.9 fn:day-from-dateTime
>        10.5.10 fn:hours-from-dateTime
>        10.5.11 fn:minutes-from-dateTime
>        10.5.12 fn:seconds-from-dateTime
>        10.5.13 fn:timezone-from-dateTime
> 
> Misc functions:
> 
> 	3. fn:error
> ERROR()
> ERROR(string)
> 
> 
> 
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Wednesday, 24 November 2010 18:13:31 UTC