For purposes of this paper, we classify technical information into two broad categories: training (knowledge transfer) and performance support (procedural diagnosis, troubleshooting, maintenance, or repair). To some degree, the content that must be delivered to users overlaps these categories; but because the goals differ in each context, so does the presentation.

In developing and delivering custom SGML and XML publishing solutions to industry and government over the years, we have observed the recurring tendency to ignore this overlap of content, and to manage training separately from performance support. This tendency is sometimes to the detriment of users, who do not see continuity from the classroom to the field. It is also inefficient in every aspect from content development to management to delivery. As technology gives rise to enterprise management of technical information, products like IETM , EPSS , and advanced user interfaces supporting diagnostics and maintenance are under pressure to show cost savings as well as benefits to accessibility of information. So we examine reusability of XML technical data to see how it can be tailored dynamically to provide a smooth, two-way transition between training and performance support.

A model that emerged years ago was to identify content as suitable for a particular, discrete level of user; say novice, intermediate, or expert. Then the software would have to determine what level of user it was dealing with, either by asking the user directly or looking at some data source to categorize them. The early implementations of this approach were to create “tracks” through the data so that only data appropriate to your level would be available to you. A more dynamic extension of this method is to provide only appropriate data at an appropriate level for every topic in the content, using the XML markup to determine what content objects to collect and how to present them.

The idea of a content pool has been “floating around” out there for years. The ISO/IEC standard Interchange Standard for Multimedia Interactive Documents (ISMID)[ISMID] defines content objects that can be collected for presentation at runtime, in response to an event. And before that, the familiar DocBook DTD defined an Information Pool with a similar purpose. ^[1] In each case, pool elements have IDs or names that can be used to retrieve them, but software has to be smart enough to pick them up in the right order and at the right time.

So there needs to be more to a content pool than just elements floating around bumping into each other. This is where our XML dynamic reuse application gets interesting, because by using a combination of direct, hierarchically structured content and creative linking techniques, we can invoke the magic of software to build a technical document by grouping topics that can change their content and their presentation on-the-fly.

An adaptive information prototype [ADAPTS] developed for the US Navy proved that delivery of XML technical information can be dynamically adjusted to a complex user model. The system provides data at an appropriate user level for every topic in the content, and blurs the line between performance support and training by enabling software to interject training content just when it is needed. To support this model, core ideas of reuse come into play because runtime screen composition requires reusable content to be packaged appropriately for each user and situation.

In developing the details of implementing this dynamic reusability model, we find that reuse occurs at multiple levels:

The key to reusability in the dynamic content selection application is defining how the same information applies in different situations. The idea is to give authors a method for defining what an element of content is all about so that automated processes can determine its applicability in a given situation. This approach is 180 degrees out from the traditional authoring process that requires authors to define explicitly the content that applies in each situation that they write about. By the traditional method, authors had to think of every situation that users might encounter. With the new method, content is applied automatically to any situation, even ones that the author didn’t know about. This enables authors to focus on the business of creating complete, accurate content and leaves the audience-driven compromises until presentation time.

One of the most difficult problems keeping us from making reusability a reality in electronic information systems is the handling of links. It is a requirement in most authoring environments that authors build explicit links to content elements that should be pulled into a topic at a particular placement. Yet when reusable content is moved to a new context, the link might need to point elsewhere, or links added or deleted. The alternative method we have developed enables the author to define rules for linking, and rely on the markup to determine how the rules are applied.

There are two parts to the markup strategy: identifying Object Types and defining Roles. Objects obviously can be defined throughout any document, but in technical maintenance documents, for example, they can usefully categorized into Object Types such as subsystems, equipment, or components that are mentioned throughout the document in many different contexts. For example, an Object Type for equipment could define the AN/PSC-5 radio set that supports DAMA SATCOM functions in a military communications suite. The technical document might contain a description of the AN/PSC-5, as well as a photo, a parts breakdown, a storage procedure, and a small training clip illustrating the radio frequency (RF) signal flow for voice and data use. Each of these data chunks plays a certain Role in describing the AN/PSC-5, because references to this equipment appear in these contexts.

To generalize the definition of Roles, we drew from the science of Information Mapping™. [Information Mapping] Based on research in cognitive science, human factors engineering, task analysis, display technology, and effective writing styles, the Information Mapping™ method provides structure for the effective representation of information. Its categorizations of information derive from research-based findings on how individuals process and understand information most efficiently.

With this strategy, reuse is supported because software can automatically look for Object Types and identify the Roles where they appear, then build a network of links to help users traverse from one context to another. Authors are not required to build explicit links, and yet the Object Type enables that content to be revealed. You can think of it as reusable linking, because the links go in all directions and bring content into relevance from places not predicted.

A generalized authoring capability, as with any product designed to serve a wide audience, comes with compromises. The generalized system enables use of a common DTD and runtime engine for a variety of applications, but requires some additional work to enable the automation we need for dynamic reuse. Our choice of the generalized approach hinges on two decisions. First, we wanted a single DTD to support multiple applications (see Figure 1); and second, the goal was to enable an author to easily identify and reuse pooled content at many levels. The authoring system enables authors to:

The generalized DTD identifies a pool of topics in contentPool that are referenced by nodeItem in the organization hierarchy.

Figure 1. Overview of the Generalized DTD

Using an explicit markup strategy (a more straight-forward case in the XML), we would define an XML content element to represent each Object Type. However, because we have chosen a generalized strategy the Object Types are defined in metadata associated with each generalized element. Possible Roles for each type of content should be customizable, and are defined by attributes in the XML.

The core content elements of the generalized DTD might have these Role attributes for an EPSS application:

Appropriate keywords to identify Object Types for each instance of a content element are stored in metadata, because they depend on the specific subject matter of the technical document. So we can get a meaningful data set via an automated query by requesting a generalized content element (e.g., a topic) of a specific Object Type (e.g., keyword = “HF-SSB subsystem”) and Role (e.g., Role attribute = “Fact”). Or to put it in plain English, our software can ask for topic elements that provide Facts about the HF-SSB subsystem.

The ability to query for content of a specific Object Type and Role offers a way to identify sharable content objects for e-learning systems (e.g., Sharable Content Object Reference Model [SCORM] ), to define XSLT for display of the content, and to individualize the presentation based on experience, preferences, or skills of users.

Reuse, in a nutshell, is the ability to use the same source content to provide different types of products. The type of product you need depends on who you are and what you are doing. So we have defined seven possible products that suit different users in different situations.

Here is a description of potential users and the situations where they may use these products (see Figure 2).

The personality of an application, which is dictated both by its user interface and its behavior (i.e., software functions), is usually tied closely to its audience by design. That might seem like stating the obvious—of course the application is designed for its users. Yet we often find that a single application is built for more than one audience while sporting a single user interface! The application we are considering here is a perfect example. We defined seven different user profiles, and now we are faced with providing an interface that is meaningful to each of them.

We can use a general categorization of the purposes for using the product—training or performance—to broad-brush the interface design. But to stop there would miss the point and the power of reusable content. We have the opportunity, using the markup strategy defining Object Types and Roles, to customize content and presentation at runtime.

So initially, we can we can break down the seven user profile types into two interfaces as follows:

Then, like the speakers in a high-fidelity music system, it all comes down the rendering. The speakers have to reproduce the original sound faithfully, but we also like to have some control to adjust it to our personal tastes. Likewise, the user interface has to reproduce the information content accurately, but our markup gives us the controls to personalize it. We can personalize:

With all this personalization, there are some tricks required of the runtime application tasked with playing back the rich content. Fortunately, there are some techniques that make even the software reusable (hey, once you have a theme, stick with it). By simply swapping out XSLT scripts we can go a long way to creating individual personalities. By isolating the rendering in its own module we gain flexibility in deployment; and a separate linking module handles the application of linking rules both to automate the creation of links and to respond to link events from the document.