Special Edition Using SGML:Developing for the World Wide Web

How to Make HyTime Links

The most important step in making HyTime links is remembering to declare the object to which you’re linking. You do this with a normal SGML ENTITY declaration that gives an appropriate public or system identifier, and the particular notation the object’s data is in.

For information about how to create ENTITY declarations, see “Specific Declarations,” p. 176

<!ENTITY graphic12 SYSTEM “C:\artwork\original\chair.gif” NDATA GIF>
<!ENTITY mysound SYSTEM “http://xyz.com/sounds/python.wav” NDATA WAV>

Once you’ve declared the external objects to which you want to refer, you can make any number of pointers to each one, or to various parts of them. The main way to do this is with what HyTime calls a nameloc, used for locations, like entities, that have specific names:

<nameloc id=nl1><nmlist nametype=entity>graphic12</></>

This might look like a lot of markup, but it has a big advantage. It separates out that object’s location or system id, and gives the object its own name (like “graphic12”) in your document. Then you can refer to it as much as you want, and only have to fix the one declaration if the object moves. This is a lot like HTML’s new BASE feature (HyTime and HTML developers do talk to each other).

Note:
There is an update to the HyTime standard that’s currently being finished. ISO calls it a technical corrigendum (or TC). It makes a number of fixes and changes, one of which is especially important here. It introduces a notion called structured system identifiers.
SGML and initial HyTime didn’t say much about the “insides” of system identifiers. Most systems only let them be paths and file names, even though that’s a restriction SGML has never required. The HyTime TC makes them a lot like URLs; they can start with a scheme name that says what follows, and then have whatever data is needed for that scheme. The TC also defines a bunch of useful schemes that you can use, much as the IETF has defined a bunch of useful schemes for URLs, like “http:” and “local:”.

The TC also adds an important link type called nlink that supports a wide range of existing linking conventions, such as the inter-book links in most industry-standard DTDs and links that work like HTML’s A element.

Finally, you make an actual link in HyTime by referring to one or more of those pointers (using an IDREF). Links can live anywhere, but the simplest case is a one-way clink that contains its own caption and points to one other place. This is like A in HTML, except that instead of an attribute with a URL, it takes an attribute with an SGML IDREF:

<clink linkend=“nl1”>Click here to see Figure 12.</clink>

The link itself has to name an IDREF as its linkend. That means it can point to another element in the same document directly, but it can also point indirectly to anything else (like an element without an ID or a graphic). To do this, it uses an IDREF to point to any HyTime “location address” element (like the nameloc elements above). Then that element points somewhere else using whatever method is needed. You can make very long chains this way if needed, but you’ll usually need only one or two steps, unless you’re managing a lot of very sophisticated interacting links.

As mentioned, the HyTime TC adds a new link type, expected to be called nlink, that lets you point directly to destinations, even if they don’t have IDs. This is how you can use HyTime to support HTML A elements directly. HREF works without changing any of what’s there already—you just add two more attributes:

• HyTime=nlink tells HyTime that the element is an nlink as HyTime understands it, even though it’s called “A.”

• notation=HTML-LINK names an SGML NOTATION, declared in the DTD. The NOTATION refers to the HTML and WWW definitions for how HTML links work. That is, they point to the documents that say things like “put a URL on the HREF attribute” and “URLs look like…”

Given that, an A that’s been modified for HyTime compatibility looks like this:

<a href=“http://xyz.org/mydocs/homepage.htm” HyTime=nlink notation=HTML
-LINK>…

The problem with this is that it looks like you have to re-write all your HTML files to add the attributes. But that’s not really true. You can leave the HTML files unchanged, and just tweak the DTD to set those attributes as defaults:

<!ATTLIST A HyTime NAME “NLINK”
notation NOTATION (HTML-LINK) HTML-LINK>

You can even use SGML’s #FIXED option to guarantee that no one sets those particular attributes to any value other than the one you specify. Having done this, you can leave the documents alone and just let the SGML parser fill in the right values as needed.

The final type of HyTime link is the most powerful. Clink and nlink both point in one direction, from a place in SGML to some other place. That is, the link must “live” right at one of its anchors. The third type, called an ilink, doesn’t have those restrictions; it lists the location addresses that lead to all of its anchors, so its own location doesn’t matter at all.

You can use ilinks to gather all your links together in one place. You can have a LINKS element at the end of your document, and collect all the links there. Better yet, you can move the links all the way out into a separate document that only has links. This can make it easier to manage the links, especially if there are a lot of them, or they connect many different documents. It also permits you to load different sets of links at different times, rather than having all links relevant to a document together even if half of them are only of interest to a few people.

For a discussion of how links work when they are completely outside of the docu-ments they link to, see “How Complex Are My References and Links?” p. 330

An ilink can also be two-way; it doesn’t matter which end you start at, you can get from either end to the other. True two-way links also stay that way—in a system without them, you have to simulate them with two one-way links, and someday when one end moves or is updated, half of a link will break.

Table of Contents