Tools

The two methods just described each require quite different tools. For client SGML software, the key question is “How fully is the SGML-aware viewer integrated with the HTML viewer?” Products vary in how they answer this question. In this case, servers don’t really need to know that they’re dealing with SGML—they just ship the bits. Therefore, the only options to figure out are at the client end. The section “SGML-aware Viewers (for CD, LAN, and Mostly WAN)” covers these options.

When the server manages SGML and converts it to HTML, many more tools come into play and you can provide a wide variety of “value-added” capabilities. The tools discussed in this chapter fall under these categories:

•  Integrated SGML converters. These sit in or immediately behind the Web server, and convert other SGML documents to HTML on the fly whenever a client requests one. Using one of these converters is the most sophisticated and feature-complete solution, but it requires more sophisticated programs at the server end.

•  Generic conversion tools. You can use these tools as “batch” converters to translate the SGML to HTML offline—you can then treat what you translated just like any other HTML. Because the SGML is gone before delivery, this solution provides less high-end functionality, but may, in some cases, be easier to manage (for example, if you have separate people responsible for data conversion and Web site management).

•  Retrieval engines. These tools keep the SGML in a relational or object-oriented database, and pull parts out as needed. They are typically closely tied to one of the other categories for batch or on-the-fly HTML conversion, but add sophisticated information retrieval and searching features. These vary greatly in ease of use.

•  The big document problem. No matter what tool you use, you’ll find that big documents pose special problems. Some tools help keep Web browsing responsive by minimizing the number of bytes that have to go across the Net at any given time.

SGML-aware Viewers (for CD, LAN, and Mostly WAN)

If the client who receives SGML data through the Web has some kind of SGML-aware viewer, he can view it. This process is straightforward, except for a couple of steps:

•  Somehow, the SGML data has to get from the program that talks to the network to the program that actually views it.

•  Somehow, the DTD, the SGML declaration, and any needed external entities need to get to the client (that is, the main SGML file [the “document entity”] itself isn’t enough).

The first problem has several solutions. The cleanest is to use a single full-function program to view HTML, SGML, graphics, and so on all in one environment (see fig. 20.1). This solution is especially easy because HTML is a special case of SGML—a generic SGML viewer should have little trouble managing HTML data.

Fig. 20.1  An integrated data viewer gives a unified interface to all the data types it supports.

You don’t have to bounce back and forth between the “HTML application” and the “SGML application” because they’re the same. You save time and screen space, and other SGML documents can appear in exactly the same window as the HTML that linked to them (and vice versa). The interface for links in all documents can work the same way as the interface for links in HTML documents, which greatly improves usability. Because the SGML viewer can talk directly to the network, it can fetch DTDs, SGML declarations, stylesheets, and external entities whenever it needs to.

---

Note:  
An SGML viewer that can talk to the network as needed has a big responsiveness advantage as well. Documents often have many, many links to other documents, references to graphics, and so on. If a viewer can’t get to those things on demand (when the user clicks on a link), the server may have to send all possible linked data ahead of time—for example, it might have to bundle up 100 graphic entities along with the document, just in case the user wants to see one. That wastes a lot of network speed and leaves the user waiting, too.

---

The problem with this approach right now is that no integrated data viewer exists. None of the Web browsers speak SGML other than HTML, and none of the SGML viewers speak to the Web. One Net-aware SGML viewer product is in beta-testing and will probably be available around the time this book appears: The DynaText SGML delivery system is adding built-in support for communication via HTTP and built-in support for HTML viewing. You can get information about it on the Net at http://www.ebt.com/.

At the other extreme, SGML can be handled by a completely separate helper application, just like unusual graphics or sound file types. When the HTML browser sees a file come in with MIME type “Text/SGML,” it simply looks up what application can handle it and forwards the data (see fig. 20.2).

Fig. 20.2  An SGML viewer can also be a helper application, called as needed by an HTML viewer.