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

On Sunday, May 26, 2013 7:17 PM, David Booth wrote:
> > 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.

It can be a relative IRI as well. In that case it gets resolved against the
currently active base IRI.


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

Yes, not recursively though but sequentially.


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

HTML allows that as well e.g.


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

And why should that be a problem?


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

It is aligned with the two RFCs. There might be a case where you can't
resolve a relative @base as the document itself has no IRI but that's the
same problem as not being able to resolve relative IRIs anywhere else in
such a document.



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 26 May 2013 22:38:02 UTC