ZnUrl isAbsolute is dubious for file urls

[kasperosterbye]

'file:///somepath' asZnUrl isAbsolute is false.

I would have expected it to be true.

The dubious part is the check for host in the implementation.

[svenvc]

Hi Kasper,

I agree that #isAbsolute and #isRelative are not crystal clear and hence maybe not that useful.

However, there is no such thing as a relative file:// reference, they are always absolute.

I don't know what you are trying to do, but if you want to combine an absolute path with a relative one, I suggest you look at #withRelativeReference: which implements a process defined in an RFC (there is also a big unit test).

Sven

[kasperosterbye]

I highly appreciate the #withRelativeReference: method - it is more than just a little useful.

The situation arose in a piece of code where I have a uri, which is either file, http, or some custom scheme type, or relative uris like 'doc/readme.md', and there was a test: myUri isAbsolute. In my concrete scenario I believe I can check on the existing of a scheme.

Feel free to close this issue if you just think I misunderstood something :-)

[svenvc]

Let's keep it open for a while as a reminder that maybe we need to improve something here.

[kasperosterbye]

One definition of isAbsolute could be based on rfc3986#appendix-A. My reading of the grammar is that absolute would be either if the URI-Reference has a scheme, or if the path starts with a /.

Now I am at it, I would have expected the last expression below to be true.

base:= 'http://a/b/c/d' asZnUrl. rel:= '../g'.
( base withRelativeReference: rel) = (base withRelativeReference: (rel asZnUrl asString))

But in the current implementation it is not (because of the implementation of ZnUrl>>parsePath: which removes '..' during parsing).