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

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
> 
> 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

> On 21 Dec 2010, at 14:09, Andy Seaborne wrote:
>> On 21/12/10 11:32, Steve Harris wrote:
>>> Why should encode_for_uri("colour"@en-GB) be a type error?
>> 
>> I'm reasonably neutral on this specific item but I'd like to address in
>> terms of the overall style.  Adding str() is not much of a burden and
>> elsewhere the argument has been made that casts and other functions are
>> needed  (e.g. aggregates over unbounds).
>> 
>> SPARQL 1.0 has regex(<uri>,..) is something that is quite common -
>> SPARQL requires a STR().
>> 
>> In other functions If the primary argument is a
>> plain-literal-with-language (PLWL), other functions return a PLWL.
> 
> 
> 
>> 
>> The hash functions should defintiely distinguish simple literals and PLWL.
>> 
>>        Andy
>> 
> 

-- 
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 14:56:48 UTC