Re: Call for Consensus: IRI resolution tests

Why does it preclude resolving absolute IRIs (the base in particular)?
(The spec does not say anything about absolute IRIs directly; it would 
have been better if it did but ...)

A nice invariant would be, informally,

resolve(base)+resolve(rel) should be the same as resolve(base+rel)

Otherwise base+relative does not lead to the same IRI depending on the 
split and number of resolutions.


Reading RFC 3986:

sec 5.2.3 merge paths.
is followed by
sec 5.2.4: Remove Dot Segments

(otherwise how does the base ever get combined with the relative part?)

so I read it that 5.2.4 is applied after combining base and relative URI 
and remove_dot_segments applies to the whole string. This is confirmed 
by 5.2.4. step 1:
"The input buffer is initialized with the *now-appended* path"


NB
The algorithm of 5.2 step 2 is a loop so A can apply later.

This seems natural because then it does not matter if a base URI has had 
remove_dot_segments applied or whether it all happens on relative URI 
sorting out.

Some cases:

Test case 1:
------------
@base <http://host/a/./> .
<urn:ex:s> <urn:ex:p> <b> .
------------
@base <http://host/> .
<urn:ex:s> <urn:ex:p> <a/./b> .
------------

and because the base itself can be relative:

Test case 2:
------------
@base <http://host/a/./> .
<urn:ex:s> <urn:ex:p> <b> .
------------
@base <http://host/a/./> .
@base <> . # Relative IRI.
<urn:ex:s> <urn:ex:p> <b> .
------------

     Andy

Received on Monday, 19 October 2015 17:49:51 UTC