The generic URI syntax actually specifies that any path segment within a URI can be divided up into parts by semicolons (or commas), and suggests using key=value as parameters within that segment.

http://tools.ietf.org/html/rfc3986#section-3.3

   For
   example, the semicolon (";") and equals ("=") reserved characters are
   often used to delimit parameters and parameter values applicable to
   that segment.  The comma (",") reserved character is often used for
   similar purposes.  For example, one URI producer might use a segment
   such as "name;v=1.1" to indicate a reference to version 1.1 of
   "name", whereas another might use a segment such as "name,1.1" to
   indicate the same

There’s no thought given as far as I can see to the relative URL concepts this matrix proposal covers, but the idea of adding key=value data in this format is supported by the RFC, and indeed in a way that supports further adding sub resources below the current one.

Which, by the way, this matrix relative URL proposal seems to ignore - how is ./subpage resolved relative to /map;x=250;y=582 ?

It did, in at least one way: https://docs.spring.io/spring-framework/reference/web/webmvc...

Semicolon is also nice on the eyes compared to '&' we're used to today.

Why in the world this didn't gain traction?

This is completely redundant w.r.t. URL parameters: ?foo=bar&etc=whatever ...

There is no need to have two competing keyword-value-list (KVL) formats in the same context.

Many comments so far seem to imply (perhaps not intentionally) that this syntax was intended only on the "right side" of the URI, but you can think of it more as adding qualifier-like information to (potentially) each path segment. So in /com/foo/bar you could further qualify foo (perhaps as /com/foo;color=yellow/bar). This can be combined with a (definitionally trailing) query string as well. Someone noted that Spring implements some support for this; the Eclipse Foundation's Jersey (Java REST toolkit) does as well if I remember right.

Alan Kay kind of said something along those lines, in that he envisioned the world wide web to be more integrative.

If we include this with Matrix URIs, we could have a scheme format that could work with remote data/objects in a convenient and logical way. RESTful APIs do not seem to be quite the same though. Like some universal API ... not sure how it would look.

If my query would be "weather?" then any API should understand this to mean I'd like to return the local weather. But as an API. Naturally we have AI now so any such queries become trivial at all times, but this is still not quite what was meant. We kind of limited things here because "all external input may be malicious". This then meant no further development in this area, because "too dangerous". Every time I try to use JavaScript to read a local file, I am reminded of that as limitation. They did not think that there are valid, non-malicious use cases, so I am using ruby and python rather than JavaScript (I could use node, but it kind of feels ... so dirty when using it).

I quite like the semi-colons. I wonder how we ended up with the slightly unwieldy ?foo=bar&some=thing

Think “how do I implement a search engine whose interface is visible in the browser address bar?” This was a reasonable question on the early web. And that’s why they are called query params.

The question mark indicates you’re making a query. And the ampersand is a boolean operator. You could imagine query params implementing | in addition to &.

I'm certain I've seen websites which used semi-colons rather than question marks and ampersands for query parameters. The Jehovah's Witnesses website used to, many years ago. I believe that one of the reasons behind this design was that it meant that there were no special characters which needed to be escaped in HTML. This design works fine for links, but not for forms, which will generate normal URLs containing question marks and ampersands. I suppose you can use POST-Redirect-GET forms, and generate your own URLs using semi-colons.

Seems Like the recommendation changed from supporting ; and & to only using &.

Thinking about it, it is a little surprising as, if I remember correctly, in HTML source you should encode & as & right?

Is there any reason we couldn't just use that anyway?