More Complex Links

Extended links give the world of linking entirely new geometries, making possible new architectures and new interfaces. Even though the “I am here—click to go there” model of the HTML A element has done an excellent job getting the Web started, it’s time to move on to “I am one part of a set—treat me as such and explore.” Extended links, multidirectional links, and out-of-line links will let developers build more intricate structures that make managing links easier in the long run.

Extended links allow developers to create groups of links, effectively providing the user (or a processing application) with a set of choices from a link rather than a single target. Even though the requirements for how an extended link must be treated by a processing application remain very loose in the working draft, the easiest way to picture an extended link is as set of choices that will appear on a pop-up menu (or other interface) to allow the user to select a direction. The classic application for this is a thesaurus. When the user clicks on a word, a set of synonyms will be listed on a pop-up menu. The user chooses from among the words and is taken to further information on the word chosen.

Implementing these links is a bit complex. As we did with simple links, we’ll start with the DTD provided by the Working Draft:

  <!ELEMENT EXTENDED ANY>
  <!ATTLIST EXTENDED
    XML-LINK        CDATA                #FIXED "EXTENDED"
    ROLE            CDATA                #IMPLIED
    TITLE           CDATA                #IMPLIED
    INLINE          (TRUE|FALSE)         "TRUE"
    CONTENT-ROLE    CDATA                #IMPLIED
    CONTENT-TITLE   CDATA                #IMPLIED
    SHOW            (EMBED|REPLACE|NEW)  "REPLACE"
    ACTUATE         (AUTO|USER)          "USER"
    BEHAVIOR        CDATA                #IMPLIED
  >

As was the case with the previous SIMPLE example, elements implementing extended links do not need to be named EXTENDED. All that is required is that the XML-LINK attribute be set to “EXTENDED”.

Our EXTENDED element is very similar to the SIMPLE element, with two changes. First, the XML-LINK attribute is now “EXTENDED” instead of “SIMPLE”. Second, the EXTENDED element has no HREF attribute. The EXTENDED element must rely on a set of subelements to contain its locators. The LOCATOR element described in the Working Draft DTD looks like:

  <!ELEMENT LOCATOR  ANY>
    <!ATTLIST LOCATOR
       XML-LINK CDATA               #FIXED "LOCATOR"
       ROLE     CDATA               #IMPLIED
       HREF     CDATA               #REQUIRED
       TITLE    CDATA               #IMPLIED
       SHOW     (EMBED|REPLACE|NEW) "REPLACE"
       ACTUATE  (AUTO|USER)         "USER"
       BEHAVIOR CDATA               #IMPLIED
    >

The LOCATOR element (which, again, needn’t be called LOCATOR) carries key linking information. The HREF carries the locator that will be used if the link is activated. The TITLE provides information that will be presented to human users, whereas ROLE carries information for the processing application. Every LOCATOR is allowed its own SHOW, ACTUATE, and BEHAVIOR as well. If the LOCATOR doesn’t specify these attributes, it should use the attribute specified in the EXTENDED element by default. This makes creating groups of links that point to different locations but share the same behavior easier, while preserving the right of individual links to behave differently when needed.

Extended links are useful in a great number of situations and may be inline or out of line. An in-line extended link might use the DTDs presented previously and look something like this:

  <EXTENDED>History Texts
  <LOCATOR TITLE="African" HREF="african.xml"/>
  <LOCATOR TITLE="Asian" HREF="asian.xml"/>
  <LOCATOR TITLE="European" HREF="european.xml"/>
  <LOCATOR TITLE="North American" HREF="namerican.xml"/>
  <LOCATOR TITLE="Pacific" HREF="pacific.xml"/>
  <LOCATOR TITLE="South American" HREF="samerican.xml"/>
  </EXTENDED>