Because SGML documents can be more demanding than HTML documents, they often require more external public resources for an SGML viewer to display those documents. But network connections sometimes break and make those resources unavailable, which causes your SGML browser to return an error. One solution to this problem is server-side validation, where the server can identify missing resources during its “off hours” and prevent your browser from returning errors when you need a file. The experience gained from the File and Audio extensions can be a beginning to this type of client/server interchange.

More for SGML To Add to HTML

The biggest thing SGML can add to HTML is nearly unlimited document diversity. There is no type of document that SGML cannot handle, and SGML specialists are trying to write DTDs for every type of document imaginable. The Text Encoding Initiative (TEI) and the Davenport Project are two such projects.

---

• See “SGML Requires More Thinking Up Front,” p. 356

• See “SGML’s Future on the Web,” p. 379

• See “Current Collaborative Projects on the Web,” p. 519

---

The trade-off is simplicity. To handle all these types of documents, you must handle all the different types of DTDs. That gets complicated. Therefore, many people don’t want to add too much to the HTML standard. They do not expect that others will learn much more about SGML.

Perhaps those same people are actually surprised by how enthusiastic everyone has been about HTML. If users are that excited by one DTD, they will appreciate the flexibility to handle multiple DTDs and applications.

---

Note:  
The goal is to expand the HTML DTD with features from SGML. The next section of this chapter talks about SGML on the Web so that you can access the documents in SGML that HTML browsers cannot. Keep in mind the distinction between upgrading the single DTD and adding the capability to handle all DTDs.

---

Future upgrades to the HTML DTD might include the following SGML features:

•  Elements that support real-time conversion of existing SGML documents into HTML documents. (This would actually be an application like SGM2HTML.exe, but the HTML DTD could be augmented to better host this kind of translation. Perhaps a special declaration that would locate this sort of utility on the Web could be added.)

•  More HyTime functionality to facilitate interfacing with multimedia applications such as video-conferencing, interactive game playing, and cable-service features over the Internet

•  Implementation features that are kept as notes in a non-local document whose location is referenced in the DTD

•  Special extensions that would allow tags for different levels of security

What SGML Can Add to Web Sites

Just think of adding the capability to use more DTDs to Web sites. If one application, HTML, has become so popular so quickly, imagine how many new applications might appear—not just extensions to existing applications. Even now, you can’t walk into the computer book section of a bookstore without being buried in books about HTML and the World Wide Web.

Part of the flexibility of SGML is that it can accommodate different applications and extensions. Virtual Reality Modeling Language (VRML), which describes three- dimensional geometry, makes virtual worlds easy to create and access, for example. Another application is Standard Music Description Language (SMDL), which was created to handle the time-sequencing information necessary to play audio files in real-time during Web sessions. Java is yet another application.

The Case for the Web to Upgrade to SGML

This question becomes whether the World Wide Web should upgrade the current standard from the HTML DTD to the entire superset of SGML capabilities.

If the World Wide Web is upgraded to SGML, you will be able to access all SGML documents, not just HTML documents, which make up only a small percentage of all the SGML documents available. The goal is not just to extend the HTML DTD with different features, but rather to be able to display any valid SGML document or its DTD.

Web browsers today follow a simple schedule. They perform a series of tasks. They scan the HTML document for tags, read the generic identifier (the tag), process the tag, and then look for the next tag.

The current Web browsing software processes the generic identifiers as the program code according to how the browser says it should. A <P> gets translated into a new paragraph because that is written into the program code. The programmer essentially decides how to process the tag. The current HTML DTD determines the list of tags—plus whatever the programmer throws in.