- From: Mike Brown <mike@skew.org>
- Date: Mon, 15 Oct 2012 02:45:44 -0600 (MDT)
- To: uri@w3.org
- CC: karld@opera.com
Karl Dubost wrote: > > As a first step towards properly defining URLs I wrote a web-compatible URL parser in JavaScript: https://github.com/annevk/url > — http://twitter.com/annevk/status/247749394093457408 > > [...] > > > URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority(). > — http://medialize.github.com/URI.js/ Oh wow, I didn't know there were more JavaScript URI libraries out there now. I'd like to incorporate their relative reference resolution functions into my in-browser test suite at <http://skew.org/uri/uri_tests.html>, but I don't know when I'm really going to get around to doing it, so don't hold your breath. Currently I only have 3 implementations being tested: - one I wrote - one TimBL wrote - a fork of one Nathan Rixham wrote (I had to fix an infinite loop bug) None of them are perfectly compliant implementations. Also, as noted on my test page, I noticed that I was expecting some "wrong" results for one of the obscure edge cases (base URI has a scheme + a relative path, no leading "/"). Actually what I am expecting is the reasonable result; it's just not what RFC 3986 says we should get. When RFC 3986/STD 66 was in development, Graham Klyne had reported this issue and suggested that the resolution algorithm be adjusted to provide a more reasonable result. There was no argument, so I assumed that the final draft would incorporate the necessary fixes. I was wrong. Mike
Received on Monday, 15 October 2012 08:46:17 UTC