- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 24 Dec 2010 11:46:13 +0000
- 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).
Andy
Received on Friday, 24 December 2010 11:46:54 UTC