The argument has been made elsewhere that I'll repeat here that the end of the dot.com era occurred because we pushed the prototype phase of the Web too far and thought it was complete. I'm a software developer. I practice a form of development that likely won't be out of place at any of your companies ­ I start with an idea, a model of where I want to go, and build it much like I would a sculpture's maquette from clay ‹ add a module here, rewrite a part of an API over there, building something up in pieces until I get about as far as I possibly can. However, and this is the important part, this maquette exists only as a prototype for me to understand what I need to do in the final product. Functionally it's a mess ­ the API may not be consistent from one class or structure to the next, the XML may be hideously non-optimal for either performance or updating, the documentation consists mainly of // To Be Written. It will work, indeed, it might work quite well because I've been doing this gig for a while, but it will be almost impossible to maintain and passing it off to another programmer at this point will frankly be an invitation for him or her to rewrite it.

However, that maquette is important to the scultor, just as the prototype is important to a software developer. It helps both of them shape their final vision, and having completed the prototype, the developer can then go in and rebuilt it right, insuring that there's fundamental integrity between and within the components, that the application is able to integrate properly, and that the resulting product is not only functional and (this is the critical thing) maintainable.

Your applications will start to become obsolete the moment the programmers stop working on it because the business cases that the software was intended to solve will change in response to changes in the business environment and change because you've solved the immediate business cases, which in turn open up possibilities that weren't open before. What this means is that your applications will spend far more time in a phase of incipient obsolescence than they did in development, which means in turn that they should be designed to age well.

Given all that, we've developed the prototype with Web 1.0, and like all too many products out there, the prototype was shipped. Web 2.0 is not a new Web, it's what happens after engineers take the crash test dummy from the 100 MPH collision with a tanker truck and examine what's left. AJAX is, as a consequence, a natural evolution of that.

Entering the Holodeck XML Messaging/XML Presentation
The issue of XML is perhaps fundamental to this whole discussion. XML is more than just a replacement for HTML, and after a decade of XML being out there I'm not going to spend any time digging into what exactly it is. If you don't know, ask your programmers. If your programmers don't know...fire them. Seriously. All of your data will eventually be moving around in XML streams of one sort or another if it doesn't already, your databases are likely increasingly speaking XQuery as well as SQL (and there are MANY MANY benefits to that), chances are that your middleware is increasingly tasked with transporting and manipulating XML, and of course your client applications are increasingly assuming one or another XML dialect to render content. That of course is not even beginning to talk about the XML services that are out there, the fact that in your verticals your customers, business partners, and competitors are already working with industry-specific XML schemas and will be expecting you to be too. If your programmers don't know the basics of working with XML then chances are pretty good they'll be a liability real soon now.

Keep in mind that XML is fundamentally a mechanism for abstraction. It's not a product ­ it's not even, technically speaking, a language. It's simply a set of conventions for structuring data in particular ways and providing means to identify compositional elements in that data. I remember one client nervously viewing the medical landscape and getting alarmed that a particular hospital group was going to XML. I was personally ecstatic ­ it meant that the application I had developed for the client would be able to work more easily there than with those groups that were still dealing with patient records on paper (or even in SQL databases). It's key to this whole Web 2.0 thing ­ the free flow of information requires a common structural language, and XML, for all its warts, is it.

However, that doesn't mean that XML by itself is the answer, and more importantly doesn't mean that XML itself hasn't been changing to reflect the evolution of the Web. In particular, there are several key aspects of XML that will likely loom large in the AJAX world, and you should be looking very carefully at these as you evaluate technological investment for the next few years.

On Impulse Power Objective XML (E4X)
This is an effort on the part of a number of different language developers to create a simplified mechanism for working with XML. JavaScript's version is called HYPERLINK "http://www.ecma-international.org/publications/standards/Ecma-357.htm" \t "_top" ECMAScript for XML (E4X), PHP calls it HYPERLINK "http://ca.php.net/simplexml" \t "_top" SimpleXML, Java has HYPERLINK "http://www.alphaworks.ibm.com/tech/xj" \t "_top" XJ, Microsoft's .NET platform has HYPERLINK "http://msdn.microsoft.com/data/ref/linq/" \t "_top" LINQ. In nearly all cases, its intent is to undo some of the verbosity introduced with the W3C's Document Object Model (DOM) API and make XML manipulation as easy as object manipulation is in most languages.

I'm Receiving a Message on a Subspace Frequency Atom and XML Syndication
Syndication is for more than just blogs. Incredible amounts of information in your system, from red shirt security types that are expendible to planets that serve Earl Grey tea can be thought of as lists that can be presented as syndicated information. Atom is an XML format designed to be a good mechanism for presenting lists of content and includes its own (openly available) publishing formats.

The fact that each Atom entry can also contain a veritable forest of links of varying types and semantics also makes it a good lightweight alternative to RDF and other relational formats, especially once people start migrating to Xquery-enabled databases.

For instance, consider as an example a set of schematic diagrams (of, say, starships just to keep in theme here), with each ship being one entry in an atom feed. Each schematic in turn contains a breakdown of the schematic by section, and each section in turn contains a list of callouts that point to specific items of interest in the schema section. If each of these lists consists of entries defined with appropriate linkage structures then this "application" essentially becomes simply a matter of pulling in external "news feeds" that contain enough data to describe particular nodes in a graph while at the same time provide unique links capable of pointing to subordinate "feeds." Certainly such information can be expressed as RDF as well, but the fixed commonality of Atom feeds means that there's typically enough to populate generalized components without requiring that "semantics" seep into the equation.

What's perhaps more compelling about such syndicated feeds is that the system for displaying them assumes that such information changes over time, that the hyperlinked lists are themselves ephemeral and have some form of time or thematic relevance. Obviously, news in general fits this bill well, but does weather information, availability of computer systems, lists of students in a given course and so forth? An Atom list is fundamentally a cohesive "editorial" unit, with all items in the list tied together by some relevant criterion.

One of the critical issues inherent in deploying Web Services has been the question of determining how to designate list or array content. If you think of an Atom feed as an array in which each entry has a minimal set of "metadata" that can provide some context for the links contained in the feed then you can do such things as build tools that will display Atom without needing to know what the specific "payload" is, which in turn makes it much easier to componentize such viewers. This is discussed more in the final section of this article about bindings and components.