Leaving aside the economic, political, and sociological answers to this question, there is at least one important respect in which I have rather undersold the case for HTML in the discussion so far. A very large proportion of the material on the web is ephemeral by design: its purpose is to make an impact in the here and now [mdash ] whether to sell a product, advertise a venue, or just make a splash. There is no reason, therefore, why its producers should treat it any more carefully than we treat paper ephemera. The difficulty arises from the fact that HTML has to be used whether we are trying to encode a monumental reference work of long term value, or to advertise the merits of the latest soft drink.
Even for documents which have a long term value, HTML really only suffers when compared to generic (i.e. extensible) SGML from an author's or publisher's standpoint. Readers, after all, don't care whether the display on their screen came from a state-of-the-art object-oriented database, from a postscript file, or by the careful application of black magic, as long as it looks nice. But many (if not most) readers would like to be author and publishers too [mdash ] that empowerment is after all what the Web was supposed to offer us. Moreover, the quality of service delivered by a network publication surely is not solely measured by the dramatic presentational effects it uses: sooner or later the reliability and sophistication of its content becomes a marketing advantage. Given this interdependence, it may be helpful to re-assess the usefulness of HTML on either side of the client/server divide.
As a server format, HTML has some fairly evident drawbacks. Despite low start-up costs, any serious long term investment in service provision based on HTML documents as the primary storage method is unlikely to be wise. The headaches of maintaining consistent links in any moderately dynamic collection simply do not bear thinking about. A hybrid system, where document management and control is carried out by a database system, linked into a static collection of HTML documents is possible, but will require as much investment as would a stand-alone native SGML document system, without any of the intrinsic benefits. At the risk of rehearsing the obvious, the advantages for server management of using a generic SGML database system are manifold:
SGML is an international standard; the products of vendors supporting it are therefore immune to current and future Internet politics, vendor wars, and ad hoc HTML extensions alike.
The extensibility of generic SGML means that documents can be marked-up according to publishers' particular needs, whether these are to satisfy niche markets or to gain competitive advantage, and also in ways appropriate to the particular type of document.
Off-the-shelf SGML tools are available to assist in the authoring of formally validated documents, and the enforcement of in-house editorial principles.
Links, indexes, and similar navigational aids can be generated directly from the structure of documents
Queries against document databases can be more precise, for example by specifying context in SGML terms; this leads to quicker and cheaper query processing with better results, at little or no additional cost.
Documents can easily be reused for a variety of purposes; variant versions (for example, printed or online, scholarly or school, full or abridged) of the same document can be generated as required, with minimal problems of internal consistency.
On-demand documents can be configured in different user-specified ways (not just different typographical treatments)
Management and administration of large document repositories is facilitated.
Transition to the future deployment of true object-oriented authoring/publishing systems is facilitated.
On the client side, the balance is in favour of HTML
Sophisticated and feature-rich browsers are already widely deployed on almost every platform.
Customization and extension of HTML browsers, whether by use of style sheets, plug-in, add-on, or mothers' little helpers, is a familiar notion to the web user community.
Simple local customization is simply done and, with the availability of style sheets, can become reasonably sophisticated, comparable with what is now available with the current generation of SGML browsers.
For the moment, it seems reasonable therefore to try to get the best of both worlds, by using SGML on the server side, with HTML as a delivery vehicle. Not only does this seem reasonable, it is indeed what a number of serious electronic publishers are already doing. Before asking whether this is indeed the optimal solution, I would like to compare two variations on this basic strategy: one in which the server does all the work, and the other in which the client does.