https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl
> On 12 Jan 2015, at 09:57, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > Hi Peter, > >> On 11 Jan 2015, at 12:47, PBKResearch <pe...@pbkresearch.co.uk> wrote: >> >> Sven >> >> Apologies for the delay in replying. >> >> Basically, the relative argument can be anything that occurs in a LINK tag >> in an HTML document. This can be anything from a file name to a complete >> address with only the 'http:' missing. >> >> I have found a couple of examples in a document from the Wikipedia >> 'Wiktionary', where I show in the attached workspace file the absolute >> address, the two relative addresses and the effect of combining using Url >> class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the >> output of the Url class>>#combine:withRelative is the expected result; in >> the first case ZnUrl>>#inContextOf: gives the expected result, in the second >> it does not. >> >> The relative address in the second case seems a bit odd (why not include the >> 'http:' and make it absolute?), but it actually occurs (quite often in >> Wiktionary files at least) and the code needs to be able to deal with it. > > The problem is that ZnUrl>>#inContextOf: works with 2 parsed URL objects. > However, relative URLs are not proper URLs and cannot be parsed nor > represented as such. For example, 'foo/bar/readme.txt' and > '/foo/bar/readme.txt' are the same. > > Relative URLs only exist while parsing and must then be resolved. Section 5 > of RFC 3968 explains in details how to do that. This will have to be added to > ZnUrl or to a helper class, but that will take some time. Luckily there are > test cases in the document. > > Thanks for the feedback. > > Sven > >> Hope this helps. >> >> Peter Kenny >> >> -----Original Message----- >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of >> Sven Van Caekenberghe >> Sent: 10 January 2015 22:56 >> To: Any question about pharo is welcome >> Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo >> 3 and Moose 5.0 >> >> Peter, >> >>> On 10 Jan 2015, at 23:30, PBKResearch <pe...@pbkresearch.co.uk> wrote: >>> >>>> Yes change the code of the Parser not to use old code. >>> As I pointed out, the Parser is a large and complex package, and I am >>> not the author, so this is easier said than done. It seems a bit odd >>> to dismiss code which worked OK in Moose 4.9, but not in Moose 5.0, as >>> 'old code.' It is code which has no functional equivalent in the new >>> code, as Sven has confirmed. >> >> Could you explain what arguments were given to the combine and what the >> expected output was/should be ? How does it use path merging ? >> >> Thx, >> >> Sven >> <CombineRelWithAbs.ws>
