For example, an HTML document is served up with a media type of text/html, but the actual information in the page is a person’s contact information marked up using hCard. An application interested in utilizing that contact information has no way of knowing whether or not the page contains that data without resorting to parsing it.

We say we want layered formats, because that’s what the combination of IETF IDs, W3C Recommendations and deployed browsers and servers allow us to say. It’s the Web version of of the Blub paradox. What we want is layered data. What we want is not just to qualify a media type, but to describe the ingredients in the entity whose “shell” is the media type.

I’d suggest that if you arrive at this point, it may indicate you’ve picked the wrong “shell.” Maybe I’m too dismissive, but I think there will always exist an impedance mismatch when attempting to define nested schemas for formats not suited to the purpose. The fact that we’ve reached a certain level of maturity with regard to extensibility (a huge engineering boon) is an exacerbating factor.

Before I get criticized for this viewpoint, I want to note explicitly that I am a proponent of microformats. I think they are incredible, and the enabling potential they offer to future browser extensions is well worth the effort in defining and developing them.

However, I believe this propensity towards nesting is ill-suited for scenarious involving structured data, often implying machine-to-machine communication. Any inadequecies inherent in media types can be easily overcome: simply define more formats that don’t necessitate deeper nesting. As a bonus, this fully complies with the REST architectural constraints.

In the address book example, HTML pages with microformats can continue to be delivered to people surfing via browsers. However, applications that are interested in structured data can request the same information be returned, not as HTML, but as vCard, a format designed specifically for the purpose of storing contact information, and delivered with a media type of text/x-vcard.

Nesting information in Atom (or RSS), while not obviating the media type issue, does not pose nearly the same problems. The reason is because Atom has a clear purpose as a container format, namely carrying a feed of items, such as news articles, that are generated over time. In contrast to the generic document markup of HTML, there are already constraints in place that should serve as guides when deciding whether or not Atom is an appropriate container.

They aren’t “browsers” because they aren’t browsing the Web. In specific, the iTunes (Music) Store is not HTML.

Unless of course you are advocating an expansion of the meaning of the term.

Rather than advocating an expansion of meaning, I’d suggest that the term has been wrongly narrowly categorized. Allow me to explain…

To begin, I’ll paraphrase the first sentence of Wikipedia’s entry on Web browser:

A web browser is a software application that enables a user to display and interact with text, images, videos, music and other information located on a network.

A typical web browser (including Internet Explorer, Safari, and Firefox), relies on three primary technologies: HTTP, HTML, and URLs.

A URL is simply an address to a resource that is available on a network. When a URL is entered into a web browser, HTTP is used to allow the web browser and a web server to communicate with one another. The server sends the browser a document marked up using HTML, which the browser is able to display on screen.

What makes the web interesting is the concept of a hyperlink.

A hyperlink is a way to point to other resources on the network. For example, links to my site can be constructed with the following HTML:

<a href="http://www.backdrifter.com/">Backdrifter</a>


The browser understands that markup and displays it as a link to my weblog. If the link is clicked, the browser will load my site. The act of browsing is simply a matter of clicking a series of links, thus loading a sequence of URLs.

Unfortunately, people tend to associate hyperlinks directly with HTML, even though their use is not limited to HTML. The Architecture of the World Wide Web describes how to apply the concept of links to non-HTML data formats.

However, I suspect the bigger objection is the use of the term “browser” for applications that don’t leave the original website. This situation occurs naturally when a server only serves links that point back to itself. It’s important to realize, though, that a subset of the web is still the web.

Returning to the original definition and the architecture guidelines published by the W3C, it is my contention that the term “web browser” makes no particular restriction on the use of transport protocol or document format. It is simply an application that allows a person to display and interact with resources represented by URLs.