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;-).

2^W: The Second Coming Of The Web

Audio

Slides (PDF)

Slides (HTML)

I recently gave a talk entitled What Comes After Web 2.0? at the W3C Technical Plenary in Boston. The humor in the talk was well appreciated; I'm posting this entry to ensure that the technical meat underlying the talk does not get overlooked.

The Importance Of Being URLAddressable

The World Wide Web was built on the following architectural pieces:

HTTP

A simple client-server protocol

HTML

A simple markup language for authoring hypertext

URLs

A universal means of addressing Web content

Where Web 1.0 was about bringing useful content to the Web, Web 2.0 is about building Web artifacts out of Web parts. URLs play a central role in enabling such re-use --- notice that a necessary and sufficient condition for something to exist on the Web is that it be addressable via a URL. A key consequence of this design is that Web artifacts when deployed on the Web themselves become an integral part of the Web and are ready to be re-used in building higher-level Web components. Here are a few illustrative examples:

Google Search

Clearly, Google WebSearch would not exist without the Web. But notice that every Google Search in its turn has a URL; this makes it possible for hypertext documents across the Web to embed links to specific searches. Thus, not only is Google Search built on the Web; it itself becomes an integral part of the Web.

Auctions

Items available on auction sites such as eBay are URL addressable. This again makes these an integral partof the Web.

Online Shopping

When items in an online catalog have URLs, each item immediately becomes part of the Web.

The overall impact of the above design is profound; by ensuring that everything that exists on the Web has a unique URL, we ensure that it becomes possible to construct higher-level Web artifacts out of existing Web parts. This is what has led to the success of mashups on the Web; notice that the typical Web mashup accesses a multiplicity of data sources via the relevant URLs to deliver an integrated view to the user.

As we look forward to the second coming of the Web where mashups are not limited to pairwise combinations of Web resources, but instead allow general composition of arbitrary combinations of Web resources, it's important to stress the following:

• Separating data, presentation and interaction into their relevant layers (HTML, CSS, JavaScript) is crucial for content re-use on the Web.
• Data access is critical for mashups that bring together multiple data sources into an integrated view. However, mashups can do much more; for example, the same mashup technologies can be leveraged to integrate multiple views of the same data to produce custom views. A good example of this is seen in the context of XForms, where the model-view separation permits the binding of multiple synchronized views to a given data-set.
• Finally, retaining the separation between data, presentation and interaction in the process of creating mashups, and ensuring that the resulting Web artifact is itself URL addressable leads to the definition of easy to use REST APIs; this is crucial for the evolution of the Web Command Line.