I know you mean well, but you cannot confuse things. Without some context, not
much can be done. #asZnUrl has totally no context.
I recently added ZnUrl>>#withRelativeReference: reference
"Return a new URL by parsing & resolving the relative reference using
myself as base URL.
This implements the process described in RFC 3986 Section 5"
See also #testReferenceResolution
The specs (RFCs) do count, the rest is often wishful thinking that does not
take all use cases into account.
Of course, ZnUrl is not the final answer to this broad problem, just some
answer that started in the HTTP world.
I don't want to change its parsing unless there is a very clear reason and
explanation why/how.
> On 13 Mar 2015, at 19:18, Norbert Hartl <[email protected]> wrote:
>
>
>> Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <[email protected]>:
>>
>>
>>> On 13 Mar 2015, at 17:20, Norbert Hartl <[email protected]> wrote:
>>>
>>> My concern is more that
>>>
>>> 'urn:foo:bar' asUrl
>>>
>>> doesn't do what it should :)
>>
>> That is because #urn is not in #schemesNotUsingDoubleSlash, it should
>> probably be added.
>>
>> But then I have to read more about it first.
>>
>> https://en.wikipedia.org/wiki/Uniform_resource_name
>
> I need to dig into it, too. I just wondered why
>
> 'abc' asUrl
>
> prints '/abc'
>
> That doesn't appear right. What do you think? It is just a URI path or a
> relative URL (depending how you like to put it). A relative URL resolved by a
> base URI will work because 'http://foo.com/foo//abc' (<— double slash) is
> still valid.
>
> I think that scheme is supposed to be a class and the parsing of the
> remaining string is delegated to that scheme. That would make it more easy to
> have URL (the locator part) as specialization to plain URI. But then it will
> make the code base a lot more complex and performance wise it probably has
> its cost. But then there would be a scheme registry that can easily extended
> by custom schemes.
>
> Just some quick thoughts,
>
> Norbert
