The Next Web?
The only things more annoying than the broken tools of today are the better tools of tomorrow which aren't here yet. Technologists often pass quickly through cycles of delight with a new toy and frustration with its limitations, looking for the next new thing as soon as they've figured out the last old thing.
Since the Web first appeared, developers have talked about what's wrong with it. (Heck, I thought HTML seemed pitifully weak compared to the hypertext work I'd been able to do in HyperCard.) Critics examined the roots of HTML structure and semantics, and the HTTP protocol on which the Web rides. Their complaints led to bursts of innovation, bursts which seemed finally to slow down as the bubble burst, Netscape left the browser field, and Microsoft let Internet Explorer stagnate.
It sometimes seems like widely popular web-standards innovation halted around 2000, and the last few years have been a period of very slow catch-up. Various visions of a new Web, a better Web, have come and gone, leaving behind useful parts but not yet transforming the Web. Are we on the edge of the next big thing? It may make sense to look at the last few big things, comparing their visions with what's happening today.
The XML Web
XML has occasionally found its way to the Web, but it's hard to remember now that once upon a time, XML was supposed to be directly on the Web, the files people loaded and manipulated. Jon Bosak and Tim Bray wrote in the May 1999 Scientific American about the benefits of changing from an HTML-based Web to an XML-based one:
As programming legend Brian Kernighan once noted, the problem with "What You See Is What You Get" is that what you see is all you've got ....
The solution, in theory, is very simple: use tags that say what the information is, not what it looks like ...
As XML spreads, the Web should become noticeably more responsive ... the structural and semantic information that can be added with XML allows these devices to do a great deal of processing on the spot. That not only will take a big load off Web servers but also should reduce network traffic dramatically.
Bosak and Bray went on to discuss the three key aspects of the XML standards family that would make this work: structure (XML), style (XSL), and linking (XLink). XLink in particular promised a huge advance on the relatively simple hypertext options HTML provided, promising much richer choices for readers and authors.
That sounded great, and I really thought I saw it happening. When I wrote the first edition of XML: A Primer, I expected my audience to be web developers looking to get started on replacing the HTML Web with the XML Web. In the second edition, I went further into that, but suddenly got a lot of complaints. XML book buyers weren't interested in the next generation of the Web. They were programmers, who just wanted to get data from point A to point B with fewer incompatibilities.
The particular XML Web described by Bosak and Bray never happened. (It still could, but hasn't.) Browser implementors, even when they supported XML, have never supported more than the tiniest subset of XLink, and XSLT support arrived slowly. Web developers, mystified by the emphasis on structure, the lack of support for XLink, and the different approach XSLT took to styling, never widely supported even the XML Web functionality subset that browser makers did implement.
Personally, I hoped for an XML+CSS+XLink web--leaving out the XSLT that was so alien to web design--but despite some promising steps forward in CSS2, it never came close to happening. Browser vendors never concluded a market existed beyond me, and the XLink never got implemented far enough to handle things like
show="embed" for images.
The XML Web never happened. It might yet, though without XLink, it seems unlikely to offer much advantage over HTML.