I recently went to an oxygen bar. What an interesting experience. If you haven’t done one of these things, its worth the trip to try it. There’s a machine that you plug into that’s got different vials of liquid in it. Each liquid has a different scent in it, like lemon, lime, lavender, etc. The oxygen is pumped through the liquid and into a tube that you stick in your nose. That’s pretty much it. You sit there and hang out and breath the oxygen.

Here’s some pictures of what they look like.

If you’re looking for some kind of euphoria, this is not the thing. I did feel pretty mellowed out after about 10 minutes of breathing in the oxygen, but that was about it. They say that its better subsequent times because you know what to look for (where have I heard that before?).

Dave

Introduction

As a proponent of using the REST architectural style for Web services
development, I’ve often been frustrated when I hear REST dismissed out of hand as a solution
for some problems, while at the same time, “document style Web services” are deemed amply suitable for it. This frustration stems from my view of REST as a generalization - an “uber architecture” of
sorts - of coarse grained, loosely coupled, document oriented approaches to application integration, which suggests to me that anything that can be accomplished with document style Web services, can be accomplished within the constraints of REST, and in a not too dissimilar way either.

In this essay, I’ll describe how core features of the Web relate to document style services, and in doing so, will describe how to build the Web with Web services.

Documents and state

“Document style” Web services are commonly characterized, not surprisingly, by messages which consist of a “document”. But what is a document? How do we know when we’re using a document or not? What isn’t a document?

What a document isn’t, at least by the (IMO, accurate) use of the term in a Web services context, is a bag-o-bits which isn’t asking anything of anyone; the current time, a purchase order, a signup sheet for pickup floor hockey. They aren’t asking anything of anyone, because their job is simply to capture state; a signup sheet captures the state of those who desire to play, a purchase order captures the state of the desire of a purchaser to acquire some goods or service, and the time, well, communicates the state of some clock.

Documents are state.

Identification and state

When dealing in documents/state, a designer often finds it useful to be able to know which documents are about the same thing. For example given two documents representing the state of some business process, it’s quite useful - and often necessary - to be able to determine if the two documents are both of the same business process even though they differ due to, perhaps, being snapshots taken at different times.

There is more than one way to address this problem, of course. One way would be to include information in the document which could be used to uniquely identify the business process; the parties involved, the time it began, etc.. While this has its advantages, it also has two large disadvantages; the inability to support alternate formats (e.g. images) which can be used to represent the state of the same business process, and that those identifying characteristics are known only to software which also knows the format. That latter problem would prevent, for example, a generic caching mechanism.

Another way, which has proven very successful on the Web, is to assign a unique URI to each business process. The URI would live outside the document (it could also live within it, but that’s optional), and could be used as a key for a cache, as it is on the Web.

Transfer and transport

This is a much more subtle point. Despite a document not asking anything of anyone, sometimes during the use of that document - particularly on its journey across a trust boundary to some other party - there comes a time when you do want to use it to ask something of someone.

Consider an electronic document containing the current time, “11:34AM”. If I transport that to some party, all I know is that it’s sitting in a buffer of some network stack; I don’t know that any application code has received it, processed it, or otherwise. This is where transfer comes in; if I successfully transfer a document, then I know that application code received it. Pictorially, it looks like this. Practically, what it means is that there is an operation being performed, just one that is uniform to all services/components (and therefore appears hidden) and means, roughly, “process this data”. The advantage of making this operation explicit rather than implicit is extensibility, as it allows us to define new operations, such as “store this data”, or “monitor this thing for state changes”.

How this would look would be that instead of sending just the bits “11:34AM”, we could send “PROCESS-THIS 11:34AM”, or “STORE-THIS 11:34AM”.

And of course, what one could achieve with the “PROCESS-THIS” and “STORE-THIS” operations would require that the protocol that defined these operations be used. They wouldn’t be “protocol independent”.

Requesting documents

Up to now, our notion of “document exchange” has been limited to “sending documents”, even if we’ve talked about sending them using different operation semantics (e.g. process vs. store). And while document submission is both necessary and powerful, there exists another interaction style which has demonstrated its utility; requesting documents.

We’ve already discussed the value of having an identifier for a business process in order to relate two documents representing the state of the same business process. Now, wouldn’t it be useful if we could “request a document” using that identifier to get the most recent state of the business process? I believe it would, and not coincidentally, this is the value of GET on the Web.

Building the Web

I explicitly avoided adding a section like this, because I was hoping people would be able to make these conclusions for themselves. But that doesn’t seem to be happening, so here it is due to popular request.

So what does this have to do with building the Web? Well, what I just described above is how one would go about turning a world of document oriented Web services, into the Web.

The first step is to start identifying those things which your documents are representations of - your resources - and to identify them with URIs. The second is to realize that can do more than just submit documents for processing (POST), you can request documents by asking for the state of a resource by invoking GET on their URIs. That’s it; that’s the Web. It’s not just for humans, it’s for any agent which can submit and request documents.

Conclusions

The relatively recent shift away from RPC and towards “document exchange” (aka state transfer) is extremely welcome progress for this POV, but IMO, just the first step of many towards fully appreciating the enormity of the World Wide Web project.

Get it? Or am I still full of it? Let me know.

Related link: http://mozwho.mozdev.org/

Bookmarks are an interesting class
of links, because they’re the most personal, and if we consider Vannevar
Bush’s “trails” to be bookmarks—or at least, a bookmark-based application—they’ve been part of the hypertext vision
since the beginning. The developers of the Mozilla add-on Mozwho realized that a cascading series of menus doesn’t have to be the only application to build around a bookmark collection, so they developed a new interface to it. Once you click on the link on http://mozwho.mozdev.org/installation.html that installs Mozwho, going to the URI chrome://mozwho/content/bookmarks.html takes you to the “Mozwho bookmarks portal,” a hierarchical series of pages that let you navigate your bookmarks. It includes a search feature that displays a report showing the links that had the search string in their title and how many of these titles were in each folder that had any hits.

Their long range goal is “to provide an adaptive homepage, customized both to you and to what your doing at the time - intertwingling multiple sources of information: rss, bookmarks, history, email.” The project’s weblog calls it “solidifying vaporware,” but they’re too modest. It already does some cool stuff well, and I look forward to their further work.

I also look forward to playing with other linking applications developed around Mozilla and Firebird. The long lists of Mozdev projects and Firebird extensions have proved that an open source approach provides a great platform for innovation, and linking technology is a clear beneficiary. I’ll let you know which other ones catch my eye.

What other interesting linking applications have been built around open-source browsers?

Related link: http://www.artima.com/intv/wiki.html

Wikis have two key features: anyone can edit any page, and they implement a markup that’s very simple while still allowing some formatting and linking. I never thought much about the implications of these features, but this artima.com interview with wiki inventor Ward Cunningham got me thinking about them more. (I don’t feel bad about missing these implications; they’re not self-evident, but evolved from the use and collective mindset of the wiki community.)

Nearly all new forms and uses of linking evolve to help navigate new forms of content. Cunningham eloquently explains that wikis are a new form of content because they provide a platform for people to express their thoughts on issues that had no platform geared to their particular issues before.

An interesting use of linking to navigate this form of content is the system for categorizing wiki pages. Not only can anyone edit wiki documents, and link to them and from them; anyone can categorize a wiki page by creating a link from it to a specialized category document identified by a string that ends with the word “Category” on some wiki systems and starts with it on others. If no appropriate category document exists, you can just create it. A backlinking feature lets you find out, while viewing any category document, which pages were classified in that category. To find out a given wiki’s collection of categories, go to its CategoryCategory page. (A google search for URLs that have “CategoryCategory” in them shows over 3,000 hits.)

To play with this feature, I went to the WikiWikiWeb wiki and created a short page about the upcoming XML 2003 conference. Because this wiki already had XML and Conference categories, I added links to those category pages at the bottom of my XMLConference page. Now, anyone who looks at either of those category pages and clicks the title at the top will see that my XML Conference page has been assigned to each of those categories. They’ll also see what other documents have been assigned to those categories, which is why this categorization system can help you learn about new issues related to your interests as well as it helps you focus directly on topics covering your interests.

The assignment of category membership is a way to add metadata, and this wiki practice demonstrates why links are a great way to do it. I once took a shot at a public, collaborative way to add metadata to existing web links, and nothing came of it, so I was very interested to come across a way that did work. It hasn’t exactly caught fire—many of the CategoryCategory pages I saw were pretty sparse—but it works, and people are using it. It’s also interesting that, although wikis generally provide a subset of web technology, their ReverseIndex feature goes beyond the web by allowing two-way links, which is why someone could find out from the CategoryConference page that I had assigned XMLConference to that category by simply adding the appropriate link to the XMLConference page. I look forward to seeing what else the wiki community creates out of these building blocks!

What else does linking provide on wikis that it doesn’t provide on the “regular” web?