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: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 24 Dec 2010 11:46:13 +0000
Message-ID: <4D148805.3000307@epimorphics.com>
To: Steve Harris <steve.harris@garlik.com>
CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>

On 21/12/10 14:56, Steve Harris wrote:
> On 2010-12-21, at 14:52, Axel Polleres wrote:
>> I see the following two options to go ahead:
>> 1) allow PLWL as input, and then also return PLWL (ie applying encode() only to the lexical form and leaving lang tag untouched, i.e.
>>     encode_for_uri("Los Angeles"@en)  -->	"Los%20Angeles"@en
>> 2) leave it "as is" i.e. require workaround encode(str()) for Steve's use case

3) Steve's suggestion the return type is always a simple literal.

>> Andy, would 1) work for you?
>> Or, Steve, is the encode(str()) workaround sufficient for you to leave the def. "as is"?
> I don't think the workaround is sufficient.
> I can't imagine that any users would expect encode_for_uri("Los Angeles"@en) to fail.
> "Los%20Angeles"@en as a return seems OK, it's a little strange at first glance, but it will tend to come out in the wash.
> - Steve

 From the POV of the function itself, (3) makes sense.  It's whether the 
overall style makes that an exception.

For (1), I think it will force a later str() when using the result so 
while it fits the style better, it isn't a real help.

So I can accept a change to (3) for this function only: return type is 
simple literal always (for xsd:string as well).

Received on Friday, 24 December 2010 11:46:54 UTC

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