Re: RDF's relative IRI resolution is ambiguous

Hi,

> s154 (should not include /ccc/)

Agree and so does my parser; forgot to correct in the gist.

> s212–s214 (should include /ccc/)

In 212, the base URL is <http://a/bb/ccc/..>, we're resolving <g>.

RFC 3986 tells us to do:

>> T.path = merge(Base.path, R.path);
>> T.path = remove_dot_segments(T.path);

and "merge" is in this case defined as:

>> return a string consisting of the reference's path component
>>       appended to all but the last segment of the base URI's path (i.e.,
>>       excluding any characters after the right-most "/" in the base URI
>>       path, or excluding the entire base URI path if it does not contain
>>       any "/" characters).


so technically, you're right and it should be <http://a/bb/ccc/g>
because ".." is the rightmost path.

However, I think we can safely agree that ".." is path with special semantics,
i.e., it is not just a path like any other, hence my result of <http://a/bb/g>

My interpretation here is that the text of RFC 3986 is written
with the silent assumption that base URI normalization is performed:

>> Normalization of the base URI, as described in Sections 6.2.2
>> and 6.2.3, is optional. 

After all, it would totally not make sense to me that
    remove_dot_segments(resolve(base, relative))
would be not equal to
    remove_dot_segments(resolve(remove_dot_segments(base), relative))
because none of the dot segments in base should possibly effect relative,
if we interpret "../" as "parent path of".

I agree that my interpretation is not what the spec says.
But I think it's what the spec meant (i.e., I see no good reason
to loose the semantics of "/.." in this one particular case).

Yet probably, we're better to follow what the spec actually says…

Best,

Ruben

Received on Thursday, 3 September 2015 18:41:22 UTC