| Previous | Table of Contents | Next |
The proposal to expand SGML capability throughout the Web implies that the browser loads the DTDs and processing rules separately for each document. The DTD and stylesheets are loaded dynamically as the browser fetches the document from the server. The browser follows a new sequence of steps. It:
- 1. Scans the document’s SGML declaration for DTD and stylesheet information and external viewer requirements.
- 2. Fetches and loads the DTD and stylesheet information if they are not already resident from the remote server.
- 3. Checks the local system for required external applications, notifies of a shortfall of resources, and initializes required programs.
- 4. Scans and processes each document tag by tag according to the applicable DTD and stylesheet information.
- 2. Fetches and loads the DTD and stylesheet information if they are not already resident from the remote server.
Each server on the Net is responsible for identifying a document as a valid SGML document.
This is just one possible scenario for a new generation of full SGML Web browsers. These browsers might be extensions or add-ons to existing HTML browsers—just as Panorama is now—or next generation browsers, such as Netscape and Mosaic, with SGML-aware coding built into them.
The advantage of this sort of capability is that each author can write his own DTD and stylesheet. The author—not a remote standards committee—has control over his document. If he needs tags that are not in the HTML feature set, he can create them. Moreover, if he wants to create a different document structural relationship between tags, he can. He does not have to follow the structural rulebook of a single DTD. He can create as unique a tag set as he needs. The document author—not the browser client programmer—controls the document.
This is the best way to go. Instead of trying to incorporate the ever-growing backlog of features into the existing HTML DTD, simply add the capability to process DTDs and stylesheets on-the-fly. The SGML standards exist. That is, most types of documents can be handled by existing DTDs, and new DTDs can be built for the exceptions. No one DTD can ever absorb all the possible features that will ever be required by any document.
What Is Needed
What is needed are SGML browsers or SGML add-ons to the existing HTML browsers. Add-on browsers, such as Panorama, are the obvious choice in the short term. Eventually, SGML-capable browsers will probably evolve. The requirements for this approach include:
- • Creating a common way of defining stylesheets so that all stylesheets can be read by the same kind of mechanism
- • Making each HTTP server responsible for having DTD and stylesheet information available for each document
- • Making each HTTP server responsible for validating its SGML documents with complete tagging
- • Standardizing HTTP header markup to facilitate the extra information
- • Making all browsers “parser smart” so that they do not duplicate what the HTTP server already should have done, or what they should not attempt to parse
- • Making all browsers support full SGML two-way links—the SGML browser must talk back to the HTML browser (under the external browser scenario)
- • Making each HTTP server responsible for having DTD and stylesheet information available for each document
Note:
A complete proposal resides on the Internet. Check out the essay by C. M. Sperberg-McQueen and Robert F. Goldstein, “HTML to the Max.” It’s available at:
With the introduction of Panorama, the SGML browsing add-on capability exists today. Other issues will take time to resolve. Some servers will get smart sooner than others, which has always been the case with servers connected to the Internet. The richer range of SGML document interchange can provide the profit incentive for all servers to catch up.
What SGML Flexibility Can Do for Web Sites
The payoff is more document diversity and function. Likewise, SGML capability in Web sites might spawn a whole new generation of clients for document browsing. New external object-oriented applications for viewing multimedia files and programs will appear even faster. Java is one example, but the specification must be configured to be SGML-friendly. In other words, the language—or future interpreted languages like Java—must conform to the requirements of SGML-friendly servers. Developers who resist SGML will have to be compatible with SGML or find another place to play.
With an SGML Web site, you can handle multiple document types—whole new applications. That is flexibility. You can use Panorama to visit some of the Web sites listed in the SoftQuad SGML tour of the World Wide Web. Pay a visit to the site shown in figure 17.1. It’s a good example. Point your Web browser (with Panorama installed) to:
- http://www.oclc.org:5046/oclc/research/panorama/panorama.html
)
Fig. 17.1 The astronomy Web site shows the same sort of eye-dazzling graphics as HTML pages, as well as all the functionality of full-blown SGML.
SGML adds many literary and mathematical possibilities. You rarely see footnotes in HTML documents. That is because two-way links are so difficult in HTML. Some good books already exist in SGML on the Web, as shown in figure 17.2.
)
Fig. 17.2 This Web site shows how easy footnotes can work in an SGML Web document.
Notice the footnotes. This type of loopback is challenging in HTML. It requires a two-way link. With SGML, this isn’t difficult because you can define both ends of the link and access it from either the jump point or the target point. Both windows of the corridor open equally well. With HTML, you need the Forward and Back buttons on the browser because links are not so robust or two-way as with a full-blown foot-note structure in SGML.
• See “Adding Hypertext Links to a Document,” p. 160• See “Footnotes and Endnotes,” p. 427
The mathematical possibilities are also useful in SGML. The following SGML Web page, shown in figure 17.3, includes NASA research data.
)
Fig. 17.3 The math capabilities of SGML Web pages appear in this NASA research report.
| Previous | Table of Contents | Next |