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

Re: Details of string operations

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 02 Dec 2010 09:37:47 +0000
Message-ID: <4CF768EB.4000704@epimorphics.com>
To: Gregory Williams <greg@evilfunhouse.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


On 02/12/10 06:28, Gregory Williams wrote:
> On Dec 1, 2010, at 5:30 PM, Andy Seaborne wrote:
>
>> Other types (including IRIs) do not get cast to string.  Add STR() or xsd:string() as needed. This is a choice point - as there are two choices for the cast STR() and xsd:string() if it were implicit, I suggest we require explicit casts.
>
> Does this mean CONCAT called with other types results in an error?

As it stands, yes.  error can be overridden.

fn:concat takes xs:anyAtomicType or empty sequence and performs a 
xsd:string cast.  fn:concat is actually rooted in XPath 1 as noted in 
F&O.  The other F&O string operations take an xsd:string or a sequence 
of xsd:strings

In SPARQL we have to copy with other types (plain literals) and we have 
IRIs.  The other string related operations do not perform the implicit 
cast and in SPARQL 1.0 regex does not, which is a source of user support 
questions but once explained I not seen an argument why it's wrong.  So 
"consistency" suggests to me that CONCAT work on strings (xsd:string, 
plain literals).  I don't have a strong opinion about this but the "IRIs 
are not strings" meme seems worth preserving.

	Andy

>
> thanks
> .greg

PS Haven't forgotten your point about TIMEZONE returning xsd:duration.
Received on Thursday, 2 December 2010 09:38:30 GMT

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