Previous Table of Contents Next


Preliminary Steps

When you add a feature such as revision tracking to a document, you must decide where and how to add it. Ask yourself these questions:

  Can I add the feature as an element tag, attribute, or entity?
  Can I avoid adding an element or entity and add an attribute instead?
  Will the feature be printed on the document, or is it nonprintable information?
  What information is in the feature?
  Whether the feature is printed or not, how is the information in the feature updated?
  Where in the document should the information be stored?

When you add a feature to the document, you need to be specific. Your intentions should be clear.

Figure 9.2 shows a technical document with a printed revision tracking feature that shows the revision level of the document. You can also show the revision level of each page, paragraph, or section in the document.


Fig. 9.2  The revision level date of this document appears on-screen.

Element or Attribute?


Tip:  
Attributes can certainly be printed values, but this example lends itself to a distinction between a printed and a nonprinted revision tracking.

If a feature will be printed, the section in which it appears could contain its own revision element. If the feature is nonprintable, you could make it an attribute of the section element. Simply place revision tags around the revision information.

For example, you can place the feature anywhere in the section, so long as the structure tree permits it within the section content model. This method works well when you are dealing with a particular date because the date can change to any date. Sometimes you have many revision levels, however, and the revision information can be expressed as only one of several alternatives—A, B, C, or D.

When there are only a few revision levels to worry about, you can add the feature with just an attribute. For example:

     <SECTION Revision="b">Section IV. Turbine Removal
     <H3>Orienting the Lifting Device</H3>
     <P>Here's the first paragraph</P>
     <P>Here's the last paragraph</P>
     <H3>Disconnecting the Turbine from the Skid</H3>
     <P>Here's the first paragraph</P>
     <P>Here's the last paragraph</P>
     <H3>Lifting the Puppy Out<H3>
     <P>Here's the first paragraph<P>
     <P>Here's the last paragraph<P>
     <H3>Taking a Bow<H3>
     </SECTION>

The attribute is set up in the DTD. Therefore, you must provide a content model for the attribute that contains all the revision levels in the DTD under the <SECTION> element.


Note:  
SGML offers many ways to add revision level tracking. For instance, you can use entities that contain other elements as content models. However, you should use the simplest method possible because it will probably be the easiest in the long run.

Adding Hypertext Links to a Document

The most common examples of adding hypertext links to a document are for HTML documents. You can easily create your own hypertext help file and work from the HTML DTD, using Netscape or another browser as your help file viewer.

Local and Remote Links

You need to distinguish between local and remote links. It’s easy to forget where files are coming from when you click a Web browser. You forget whether the document that you are accessing is on your own hard drive or local network, or whether it’s from a server on the other side of the planet. Local and remote links are an important distinction in SGML, however, because you must mark them differently.

In HTML, a local reference in a Web document is usually indicated by:

     <A HREF="home.htm">Jump to My Home Page</A>

and a remote reference is usually indicated by:

     <A HREF="http://www.someplace.com">Jump to my page</A>

There are variations, but these follow the basic DTD. In figure 9.3, you can see the delimiters and attribute format that surrounds the tagged text.


Fig. 9.3  Netscape’s online handbook contains references to hypertext links that include special Netscape extensions.

Sometimes you want to link to a local graphics image, which is another type of link. In the HTML DTD, a call to the graphic looks like:

     <IMG SRC = "graphic.gif"><PARA>Bla bla bla bla</PARA>

All the elements are defined in the appropriate definition for the document type for the DTD. In the HTML 2.0 DTD, the line markup section calls the <A> element—short for anchor—with attributes:

     <!ELEMENT A      - - %A.content -(A)>
     <!ATTLIST A
          HREF  %URI #IMPLIED
          NAME  %linkName #IMPLIED
          %linkExtraAttributes;
          %SDAPREF; "<Anchor: #AttList>"
          >

Notice the HREF attribute with the %URI content model. This is just one example of how a DTD makes a link.


Note:  
The HTML DTD is somewhat limited in its linking capability. More robust links can be created in SGML using ID and IDREF attributes described in “Identifying Internal and External Objects (ID & IDREF)” in Chapter 14.

Also note that URI (universal resource indicator) is a more generic term than URL (universal resource link). A URL is only one kind of URI.


Adding Multimedia Content

Adding multimedia capability to documents essentially involves linking them to other types of files. Your documents are primarily text documents. You are pointing to binary files or executable programs. SGML handles this well, but it must turn over control of this type of file to a specialized viewer.

Suppose, for example, that you want to put a button that starts an audio-visual film clip on one of your document instances. When you point to the clip file, the SGML processing system gives control over the binary media file to the appropriate viewer. When the clip finishes, the control returns to the SGML tool. Much of this depends on the characteristics of the browsing tool that you use to look at the SGML file. With Web documents, the job of SGML is to point to the target file and to keep the link clear.


Previous Table of Contents Next