Since an ilink doesn’t live at one end, there’s no particular reason you can only have a total of two ends. You can have as many as you want. Most people find it a little hard to imagine, at first, just why you would want more than two ends to a link, but there are a lot of useful cases. Suppose you’re writing a comparison between two earlier documents: you might want a link that points to part of one document, to a related part of the other, and to your comment about how they’re related. That’s three ends; to create a link connecting all of them, you’d use an ilink.

An ilink looks a lot like a clink, but doesn’t need any content inside it to have a source anchor. Depending on how you set up your ilinks in the DTD, they can contain content, but, even so, the content isn’t necessarily an anchor of the link. Like clink, ilink specifies its linkends with IDREFs, but on an attribute called “linkends” instead of just “linkend” (not very surprising, right?). The IDREFs can point either directly to anchors (for anchors that are elements in the same document, and that have IDs to point to), or indirectly, by pointing to location address elements that eventually lead to the anchors.

Here’s an example of an ilink with three ends:

<p id=p1>The telephone was invented by Bell</p>
<p id=p2>The telephone was invented by Ring</p>
<p id=p3>“Bell” is the correct answer.</p>
<ilink linkends=“p1 p2 p3”>

The ilink just says that p1, p2, and p3 are related. There are some other constraints that you don’t need much detail about. For example, you must declare a different SGML element type for ilinks with two ends, ilinks with three ends, and so on, as far as needed (you give them all attribute “HyTime=ilink” so a HyTime program can find them even though they have different names). Each kind of ilink also specifies a fixed set of anchor roles, a name for each anchor that (hopefully) describes its purpose. In this example, appropriate anchor roles might be “Quote Quote Comment” (to apply to the three ends in order—here p1, p2, and p3 ). Figure 22.2 is a diagram of such a link.

Fig. 22.2  HyTime “ilinks” don’t live at any of their actual ends, but can go anywhere—so they can have any number of ends.

There’s lots more to HyTime than this chapter can even begin to talk about, including many features for dealing with graphic, video, and other multimedia data. But this should give you a flavor for the kinds of powerful linking it provides.

How To Make Effective SGML Web Pages

Making a splash on the Web is a combination of many things. A lot of them have nothing to do with markup or even functionality. Probably the most important of all is that the information itself be interesting. You’ve probably sat through someone’s pictures from a family vacation, and unless there’s something more to it than that, it can be pretty boring. On the other hand, every now and then someone can do an amazing presentation of something that simple, and it will be remembered fondly for a long time. It probably has a lot to do with showmanship, photographic skills, and even tone of voice.

SGML won’t buy you any of those things. Neither will HTML, JPEG, the latest hi-res color screen, or the fastest Internet connection in the world. Your information has to be interesting before you can really get off the ground. But suppose you get that far; you decided what you want to say, it’s really interesting, and you even know how to say it in words and pictures. Once you have that, presentation skills and technology start to come into play: How well can your medium communicate your message? Can it at all? How do you organize your presentation? How do you make it flow? You can make a huge difference by using the best tools for the job.

Support for More Kinds of Documents

With HTML, you must fit all the parts of your information into one of a few categories; there only are so many categories to go around. If you want subtle distinctions, you can’t have elements for them, whether or not you want them to affect formatting.

One solution in HTML is to move some of your information into other media altogether—changing document portions into graphics or sound. It’s very important to be able to do this when you want to—the problem is when you have to do it even if you don’t want to. The most common case of that is equations. If you want to put information on the Web that has even simple math in it, like a Web site designed to help junior high students with math, or a guide to home mortgages or other things that involve financial calculations, there isn’t a lot of help from the technology. Usually, you can do one of three things:

•  Wait for HTML to add direct support for displaying equations. People are working on this, but it’s not there yet, and it may be a while before a really complete solution arrives because formatting math is complicated.

•  Do your equations in something else (often TeX) and then save the output as a bitmap graphic, like a GIF file. This lets Web browsers display them inline, but they usually look pretty ugly, especially if you try to scale them up or down. Also, small characters, such as superscripts, can become small enough to drop out.

•  Use a “helper application” to display equations stored in some other format, like TeX, DVI, or PostScript. This will look a lot better, but requires special plug-ins if the equations are to appear inline as if they were really part of the HTML (and at least right now, those plug-ins don’t work across different browsers).

Equations in math and accounting documents are just one example. Lots of documents need their own kinds of elements. SGML, of course, lets you support new kinds of objects as needed. SGML programs still need to support the concept of “equations” in their stylesheets—it wouldn’t do much good to recognize a “superscript” tag if all you could do with it was to make it bold or italic! But the most basic assumption in an SGML system is that you’ll be seeing new tags often, which you better be able to support, so the chance of being able to rig up an SGML system to render even a very bizarre new tag is pretty good.