Toward URL Equality For Web Clients And Web Servers

In response to my previous post on the second coming of the Web, Mark Birbeck commented on the power of the Web Command line and went on to right an extremely insightful article on Passing command line arguments via XPointer. His article provides a concrete example of how his Web application container (Sidewinder) leverages the XPointer syntax to pass parameters to the Web application that is being invoked. But his article also succinctly points out what has been a glaring inequality between Web servers and Web clients when it comes to URLs. The Web server and Web client started off as equals at the inception of the Web in this regard ? indicated server-side URL-params, while # stood for client-side URL-params. The the last 10 years have seen the Web successfully use URL parameters on the server-side to achieve the RESTful Web in all its glory. In stark contrast, URL intelligence on the client-side has been stagnant at where it was in 1992 in that the only client-side parameter that can be passed via a URL is the id of the element to which the client should jump upon opening the document.

To achieve equality among Web servers and Web clients in this regard, it is perhaps time that the Web started innovating with respect to the use of client-side URL parameters. Here is a wish-list of things that one might wish to achieve using such client-side URL params --- from here on, let's once again think ? for the server, # for the client.

Specify initial location

Already achieved via <URL>#id

Set style

Open a URL with a user-specified style that is chosen among the several alternatives offered by a site, e.g.: <URL>#style(high-contrast.css).

Filter a document

Filter a document by a given XPath expression: <url>#xpath-filter(expression).

And a lot more than can fit in this margin...

Note that all of the XPointer syntax sketched out above should be taken with a large grain of salt --- the goal here is to speculate, not specify;-).