> Am 13.03.2015 um 20:04 schrieb Sven Van Caekenberghe <[email protected]>: > > I know you mean well, but you cannot confuse things. Without some context, > not much can be done. #asZnUrl has totally no context. > Maybe this is misunderstanding. My point was that there is no context given by #asUrl. So it is not a locator at all therefor the leading slash is confusing to me.
> 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. > Agreed, I'll consult the specs again. > 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. > I didn't want to complain. Your stuff is pretty awesome and there should be really good reasons to change it. History just introduced the ambiguity between URL and URl. An URI is just an identifier. A scheme puts additional meaning on how to interpret stuff. Sorry if I confused anything. Norbert >> 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 > >
