Re: Turtle syntax: Please align base URI with RFC 3986 & 3987

Hi Andy,

On 05/26/2013 10:39 AM, Andy Seaborne wrote:
> David,
>
> Isn't that covered by:
>
> "If the base URI is obtained from a URI reference,  ..."

That isn't the case I'm concerned about.  I'm concerned about the case 
where the base URI is specified using @base.

>
> The syntax has
>
> @base IRIREF .
>
> and the @base is no different to other URIs - it is subject to URI
> resolution.

But I don't see anything there that explicitly requires IRIREF to be an 
absolute-IRI as defined in RFC3987.  Other parts of the Turtle syntax 
(such as the @prefix production) also use the IRIREF syntax production 
without requiring it to be an absolute-IRI.  That's why it isn't clear 
that in the case of @base it must be an absolute-IRI.

> Sec 7.2 of the Turtle spec about IRIREF.

AFAICT section 7.2
http://www.w3.org/TR/turtle/#handle-IRIREF
just refers back to section 6.3.  It says: 'The characters between "<" 
and ">" are taken, with the numeric escape sequences unescaped, to form 
the unicode string of the IRI. Relative IRI resolution is performed per 
section 6.3 IRI References.'

>
> The text inside <...> is not the exact characters to be used.
>
> Hence, the "obtained" text applies.
>
> @base <relURI> .
>
> is also legal as is
>
> @base <../sibling> .
>
> which might be occasionally useful.

Huh?  Are you saying that @base can recursively specify the base URI 
using a *relative* URI?  Then there would have to be a base URI of the 
@base URI?

I'm very surprised to hear you say that a relative @base URI would be 
legal.  I don't think that should be allowed.  That seems too mysterious 
and error prone to me.   That would require a relative URI specified in 
@base to be resolved using "Reference Resolution", which is specified in 
section 5 of RFC 3986.  But the result of "Reference Resolution" is "a 
string matching the <URI> syntax rule of Section 3", and the <URI> 
production *allows* a fragment identifier.

I think it would be better to align directly with SPARQL and RFC 3986 
and RFC 3987 by explicitly requiring @base to specify an absolute-IRI.

David

>
>      Andy
>
> On 26/05/13 04:03, David Booth wrote:
>> AFAICT, the current Turtle syntax rules permit a base IRI
>> http://www.w3.org/TR/turtle/#grammar-production-base
>> to include a hash ("#"):
>>
>>    BASE <http://example/foo#>
>>
>> However, the URI specification, RFC 3986,
>> http://www.ietf.org/rfc/rfc3986.txt
>> in section 5.1 forbids a hash in a base URI:
>>
>>     "A base URI
>>     must conform to the <absolute-URI> syntax rule (Section 4.3).  If the
>>     base URI is obtained from a URI reference, then that reference must
>>     be converted to absolute form and stripped of any fragment component
>>     prior to its use as a base URI."
>>
>> Turtle spec section 6.3
>> http://www.w3.org/TR/turtle/#sec-iri-references
>> does refer to other portions of RFC 3986, but not the portion that
>> requires the base URI to be an absolute URI.
>>
>> Please align the Turtle spec with RDF 3986 by requiring that a base URI
>> be an absolute-IRI as defined in RFC 3987.
>>
>> I see that the SPARQL spec does explicitly say:
>> http://www.w3.org/TR/sparql11-query/#iriRefs
>> "Base IRIs declared with the BASE keyword must be absolute IRIs".
>
> The section also links to 4.1.1 which discusses syntax and the process
> of getting an absolute IRI.
>
> 1.2.4 says:
> The abbreviated forms (relative IRIs and prefixed names) in the SPARQL
> syntax are resolved to produce absolute IRIs.
>
> A relative URI syntax can be given to BASE - the text is just
> emphasising that the base used to resolve is not just the characters
> inside <...>.
>
>
>>
>> Therefore, I suggest:
>>
>>   - Add the following sentence to section 6.3: "Base IRIs declared with
>> the @base or BASE keyword must be absolute-IRIs as defined in RFC3987."
>>
>>   - Add the following comment to syntax rules 5 and 5s:
>>
>> [5]     base     ::=     '@base' IRIREF '.'      /* See also Sec. 6.3 */
>> [5s]     sparqlBase     ::=     "BASE" IRIREF   /* See also Sec. 6.3 */
>>
>> Thanks,
>> David
>>
>>
>>
>
>
>
>

Received on Sunday, 26 May 2013 22:17:45 UTC