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

Re: rq25.xml String functions definitions - first shot (ACTION-350)

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 21 Dec 2010 11:32:25 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <A028F26F-D975-4062-921F-8418C5414DF0@garlik.com>
To: Axel Polleres <axel.polleres@deri.org>
On 2010-12-20, at 18:37, Axel Polleres wrote:
>          <p>The <code>encode</code> function is SPARQL's correspondent to the XPath <a href="http://www.w3.org/TR/xpath-functions/#func-encode-for-uri">fn:encode-for-uri</a> function and accepts simple literals  as well as <code>xsd:string</code> typed literals as input. It returns a simple literal with the lexical form obtained from the lexical form of its input after translating reserved characters according to the <a href="http://www.w3.org/TR/xpath-functions/#func-encode-for-uri">fn:encode-for-uri</a> function. For plain literals with language tag or typed literals with types other than <code>xsd:string</code> it returns a <a href="http://www.w3.org/TR/xquery/#dt-type-error" class="norm">type error</a>.</p>

Why should encode_for_uri("colour"@en-GB) be a type error?

I can understand that encode_for_uri("1"^^xsd:integer) could/should be a type error, because you can't encode the integer one in a URI, but you can encode the English word "colour" in a URI.

There's arguably some information loss, as you lose the language tag, but as URIs can't capture language tags I don't see that as an issue (like STR() and simple literals).

- Steve

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 Tuesday, 21 December 2010 11:32:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:02 UTC