"Except URI's aren't uniform."

Sure they are! They're structured data serialized to a binary blob that claims to be a string but contains no encoding indication with guidance given by an internet standard for the contents of the string before the first colon but no guidance whatsoever after that! What's not uniform about that?

Normally I wouldn't be so pedantic but at the point where you're talking about "mysql://myuser:mypass@db8.myhost.com:3306/mydatabase" as if it's some sort of solution to a problem you've really dropped the ball.

URLs are only meaningful in a given semantic context. "http" and "https" are meaningful because we all agree what they mean (see RFCs below). "git" is meaningful-ish because there's only one thing that plausibly can be said to give a definition, but your application does not magically gain any understanding of the subsequent what-might-as-well-be-a-binary-blob merely by virtue of sticking "git:" in front of it. "mysql" is simply meaningless. I use Perl and therefore DBI and I observe that it too has a sort of "mysql URL" but it looks nothing like Ruby's. Uniformity is relatively to a universal agreement about what it means, and mysql lacks that. For that matter, git may very well lack it in the future, if someone implements other gits (and I've seen attempts). Without that universal agreement, you don't have a URL. You can't make a URL by fiat.

For non-standard URLs, what follows the colon... and for that matter what precedes it... is nothing more and nothing less than a binary blob in a constrained character set. And this article should be treated exactly as if it were an article about how all your resource location problems go away if you just express them in terms of opaque binary blobs, because once you leave http and https behind, that is what you are doing. Not "like" what you are doing, it is what you are doing, full stop. It may work for you and it may work for your friends, but that is not by the magic of calling your binary blob a URL, it is by the magic of agreeing to a way to interpret bits, and that's hardly any sort of breakthrough.

(Just to be clear, this is vehement agreement that acknowledges that you got to this point first.)

By the way, since I can already guess that someone will reply with something like m0th87's point, I invite you to read the URL RFC: http://www.ietf.org/rfc/rfc1738.txt But read it carefully, for what it actually mandates. Section 2.2: "Many URL schemes reserve certain characters for a special meaning"... none of them are universal to URLs, they are all scheme-specific, which means you can't trust their meaning in undefined schemes. Section 2.3: "Some URL schemes ... contain names that can be considered hierarchial"... / doesn't have a universal meaning, it's relative to the scheme. 3.1 describes the double-slash, which I can now say I've seen used incorrectly in both directions. Section 3.5 defining "mailto:" observes that URLs aren't even necessarily resources. (Section 3.10, file URLs defined in a way that violates the earlier discussion of double-slash. I understand why, but it's still a violation.)

And if you want to talk URI (http://www.ietf.org/rfc/rfc2396.txt ), section 3 starts right off with "The URI syntax is dependent upon the scheme."