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

Re: [TF-PP] IRI and base URIs

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Thu, 27 May 2010 12:08:52 +0100
Message-ID: <4BFE52C4.7060002@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


On 27/05/2010 11:39 AM, Steve Harris wrote:
> I would very much like it to be defined for IRI inputs too,
Yes, that's sensible.

> As per the subject, is IRI("foo") intended to return<foo>  relative to the base, or be an error?

Defined as error.  <foo> is not an absolute IRI.  What I don't want is 
making it spec-legal to generate relative IRIs when RDF s defined around 
absolute URIs.

Your implementation can do different, errors are an extension point.

(There isn't a sensible base anyway.  If the data comes from several 
files, there isn't necessary one base anyway.  The base of the query is 
accessible if really needed, and if there is one, but that can be used 
by the application writer anyway with str(<>))

	Andy

>
> - Steve
>
> On 2010-05-27, at 10:45, Andy Seaborne wrote:
>
>> While we're in and around the subject of base URIs:
>>
>> The IRI function takes a string and produces an IRI: I propose that we define it only for valid, absolute IRIs, and anything else is an error.
>>
>> Creating relative IRIs is plain bad, albeit occasionally necessary.
>>
>> Errors in SPARQL can be replaced in an implementation by doing something but it indicates the something outside the spec.
>>
>> IRI("foo")
>> IRI("http://example/a space")
>> IRI("http://example/[]")
>> IRI("http://192.168.1.999/a")
>>
>> The string is not automatically %-encoded - if that's needed, then call another function to perform the operation.
>>
>> 	Andy
>>
>
Received on Thursday, 27 May 2010 11:09:23 GMT

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