MID 
MID Relationship
| Charles F. Goldfarb - The HyTime Technical Corrigendum - Part 1 | Table of contents | Indexes | Eliot Kimber - Property Sets and Groves | |||
| Cooper, David W. MID MID Relationship | Cooper David W. |
HyMID Relationships |
| Hyperlink | Hyperlinking with MID's <relationship> element |
Background |
| HyMID Metafile for Interactive Documents | The Metafile for Interactive Documents (MID) is a proposed standard governing transport of interactive hypermedia information. The project has undergone two years of development under U.S. Navy R&D funding, and has been validated by software implementation in the form of a public domain MID document browser called HyMID. ( NOTE: HyMID is available for download from [ http://navycals.dt.navy.mil/mid/mid.html ].) |
| MID Instance | MID is an interchange structure that conforms with ISO 8879 (SGML), and applies techniques defined in ISO/IEC 10744 (HyTime) to reference multimedia data that resides within a bounded set of distributed source files and databases. Instructions for rendering of the data may be specified by MID authors, along with the conditions determining which instructions are to be executed at runtime in any presentation software. It is desirable for data sources to remain neutral of any processing or presentation semantics, maximizing their reusability in various contexts. A MID instance, then, will be a hub document that references both internal and external data sources, and governs the order and conditions of their presentation. |
| HyTime Technical Corrigendum MID DTD | The MID Document Type Definition (DTD) defines the mechanism for creating portable hypermedia documents that can be described in terms of the following base architectures. ( NOTE: The HyTime Technical Corrigendum defines a way to form sets of base SGML architectures.) |
|
| Data Structures | MID applies the HyTime architecture exclusively in defining the mechanism for data view and access, but defines most of the other three base architectures internally. One exception is in the information modeling architecture, which includes an element defining relationships among data objects. |
The relationship element |
| Architectural Form Ilink MID DTD Relationship | The relationship conforms to the architecture for a HyTimeilink . It expresses an authored association between two identified objects. Each MID document instance must provide its own element and attribute declarations in accordance with the HyTime standard. A pseudo-declaration is provided in the MID DTD as a model for the HyTimeilink . The pseudo-declaration in the MID DTD is an architectural form forrelationship elements defined each MID instance. The generic identifier of therelationship elements declared in the document instance govern the relationship semantic. |
| MID DTD | Here is the relationship element pseudo-declaration as it appears in the MID DTD: |
| RelationshipName | The relationshipName attribute is a displayable string that indicates the purpose of each element that is derived from the relationship form. |
| MID attribute | The MID attribute associates derived elements with therelationship form pseudo-declaration. |
| Anchrole Linkend PrivTrav Relationship | The privTrav contains none, one, or all of theanchrole names. Its purpose is to define a default traversal from none, all, or eachlinkend to anotherlinkend within therelationship . |
| Gosub Goto Spawn Traversal | The traversal semantic is governed by the traversal attribute. Iftraversal is set to beundefined , traversal decisions will be left up to the application. The other listed types (i.e.,gosub |spawn |goto ) imply display characteristics for the transition resulting from the traversal, and affect the scope of variables used to govern the transition. They are defined in the MID scripting facilities. |
| All other attributes are defined in the HyTime standard. |
Getting ready for a MID relationship |
| IETM | The following example has been created from a rudimentary technical manual for an aircraft generator set. A more extensive example using the same technical manual data is included with the HyMID software that is in the public domain. |
| Hyperlink | The generator set contains engine components, which in turn contain ignition components. Two components of the ignition system, the Ignition Coil and theMagneto Rotor , will be the focus of this example. With this limitation, a more complete view of the operation of therelationship element for implementing hyperlinking between text and graphic objects will be possible. |
| HotObjects Hotspot Object Relationship Generic Identifier Zonelist | For the generator's interactive technical manual we create three elements in the MID instance (i.e., equipment ,hotObjects , andzonelist ) that are based on therelationship pseudo-declaration. Theequipment relationship is used to identify the occurrences of an equipment component reference within specific contexts throughout the document. Theequipment relationship will be used to locate other relevant information about a component by clicking on an occurrence of that component in text or graphics. |
| CApH HotObjects MID author Object Topic Map | A separate relationship,hotObjects , is created to enable the MID author to relate an unlimited number of hyperlinkable objects (represented by hotwords and hotzones) to a topic definition. The topic definition may be, for example an index or glossary entry. ThehotObjects anchors share a common semantic, and their relationship can be considered a semantic assignment as defined in the Topic Navigation Map module of the Conventions for the Application of HyTime (CApH). (NOTE: Information on CApH semantic assignments and the Topic Map Navigation module can be obtained from [ http://www.hightext.com ].) |
| Hotspot Zonelist | Thezonelist relationship expresses the association of a graphic file (in any declared format) with the named objects within that graphic file that need to be referenced externally. This allows us to quickly identify the areas or objects in a graphic that need to accept user input when the graphic is rendered. |
| Hotspot | Identifying text hotspots |
| Container InfoContainer Pane | A MIDinfoContainer element is a fundamental building block of a MID instance that delimits a set of information an authors intends will be rendered together. Within aninfoContainer ,panes are used to either contain or refer to data content—they may be grouped and arranged hierarchically to provide a browser with cues for rendering decisions. |
| Anchor HotObjects Object Pane SGML SpecialText | A textpane can contain (via the defined SGML hierarchy) one or more occurrences of the elementspecialText , used in this case to identify ananchor for reference by thehotObjects relationship. |
| Hotspot | Identifying graphic hotspots |
| Entity Notation | Both graphics files and the named objects within the files are referenced by entities . For graphics files, anotation declaration is also required. |
Assigning names |
| Docorsub Element Entity Nameloc | For maximum flexibility in referencing theelements andentities that will be used inrelationships , we add a layer ofnamelocs . During maintenance of information, authors are then free, for example, to moveelements andentity declarations among files. The only requirement would be to change or add adocorsub attribute to the referencingnameloc . |
 |
| Container InfoContainer Nameloc | Figure 1. Namelocs to infoContainer and specialText |
 |
| Hotspot Nameloc | Figure 2. Namelocs applied to graphics file and hotzone entities |
| Aggregate Anchor HotObjects Linkends Object | For somerelationships , it is beneficial to use anaggregate link. By contrast, theequipment relationship uses a fixed number oflinkends to enforce structure. Authors must select the most appropriateanchor of each type to reference. However, in the case of thehotObjects relationship, it is advantageous to leave the number oflinkends open. |
Aggregate namelocs |
| Agglink Aggregate Container HotObjects InfoContainer Linkend Nameloc Nmlist Object | Recall that thehotObjects relationship defines topics that are semantically linked. It is not possible to predict exactly how many hotspots in text and graphics will need to be applied to a specific topic, nor is it desirable to identify the specific roles for each anchor. As in a Topic Navigation Map, thehotObjects element defines anaggregate (#agg) linkend . To take advantage of theaggregate , we use anameloc with theaggloc attribute set, allowing multiple elements in the enclosednmlist . As we have referred to all hotwords and hotzones using othernameloc elements, we can use a singlenmlist to gather up all the occurrences of the topic, including anyinfoContainers that contain specific content for the topic. For this example, we will include theinfoContainer IgnitionCoilDesc (shown previously) in anaggregate nameloc that includes other objects that are semantically related to it. |
 |
Figure 3. Aggregate nameloc for hotObjects |
<!-- Nameloc referencing hotzones in the ignition.shg graphic * --> <nameloc id=IgnitionZones aggloc=aggloc> <nmlist element nobnames> hzIgnitionCoilLoc hzMagnetoRotorLoc </nmlist> </nameloc> |
Example MID relationships |
Equipment relationship |
| Anchrole Container InfoContainer Nameloc Relationship Generic Identifier | Theequipment linkends point to descriptive text, parts list, and illustrated parts breakdown (IPB)infoContainers , vianamelocs . Theanchroles may be used by MID browsers to list the optional paths that may be traversed by users. |
HotObjects relationship |
| HotObjects Hotspot Object Relationship Generic Identifier | ThehotObjects relationship connects a topic to its list of occurrences in various contexts. In our example technical manual, the objects comprise both hotwords and hotzones. |
| Aggregate Anchor Anchrole Linkend Object | Note that in the case of anaggregate linkend (such as is identified by theanchrole Objects #agg below), the application can't use theanchroles to identify optional paths to users. The application must derive a displayable name for each link that would allow a user to determine which link he desires to traverse. The displayable names may, for example, be derived from the title or content of each destinationanchor . |
Zonelist relationship |
| Hotspot Relationship Generic Identifier Zonelist | Thezonelist connects a graphic (or potentially another multimedia file format) to its list of named objects. In our example technical manual we use a bitmap graphic format, so the objects in the graphic are identified by coordinate zones. In another file format the objects may be identified directly, e.g., as a group of primitives. |
| Anchor Container Extra HotObjects Intra Object Traversal | The purpose of the zonelist relationship is to identify to the MID browser all the objects that should be considered hotspots when the graphic is rendered. ThehotObjects relationship determines what happens when a user clicks on a hotspot. To avoid confusion, we restrict the traversal to and from theanchors identified in thezonelist relationship by setting theextra andintra attributes. Traversal from sharedanchors is determined solely by thehotObjects relationship. |
| Any | Because both the extra andintra attributes carry the same values the rules apply to traversal regardless of how you arrived at the anchor.Any traversal is allowable from withincontainers , but onlyexternal traversals are allowed from any of thezones . Therefore, traversal from zones are restricted to only those defined in non-zonelist-typerelationships . |
Using the relationships |
| Recall that we have identified the following types of declarations in previous discussion. |
| Container InfoContainer SpecialText | An infoContainer , which may havespecialText anchors within it (to be referenced as hotwords): |
<infoContainer id= IgnitionCoilDesc> ... <paragraph>Click here for other <specialText type=anchor id=hwIgnitionCoilLinks> ignition coil </specialText> references.</paragraph> </infoContainer> |
| Entity declarations Notation | Notation and entity declarations for a graphics file and its named hotzones: |
| Container InfoContainer Nameloc | Namelocs for the infoContainer , the graphic, the hotwords, and the graphic hotzones: |
| Aggregate namelocs for referencing varying numbers of anchors having a common anchrole : |
<nameloc id=IgnitionCoilLoc aggloc=agglink> <nmlist element nobnames> hzIgnitionCoilLoc hwIgnitionCoilLoc hwIgnitionCoilLinksLoc IgnitionCoilDesc </nmlist> </nameloc> |
| Relationship Relationship example | Now, here are some of the relationships that the example MID instance uses to link information in the defined ways. The IDs and names correspond with the MID instance filesmidair.mdf (the hub document) andmidmag.msf (the external MID support file referenced from the MID hub document). |
 |
| Container InfoContainer | Figure 4. The equipment relationship points to infoContainers via namelocs |
 |
| HotObjects Hotspot Object | Figure 5. The hotObjects relationship associates hotspots with a topic |
<!-- zonelist relationship for the Ignition System IPB diagram * --> <zonelist linkends="IPBIgnitionShgloc IgnitionZones"> <title>Ignition Zones</title> </zonelist> |
 |
| Figure 6. The zonelist relationship identifies all the zones in a graphics file |
Summary |
| Architectural Form Ilink Relationship | MID relationships serve many functions critical to successful hypermedia presentations. As demonstrated with the HyMID software and example MID instances, these functions can also be handled in a generalized way that promotes the reuse and the long-term maintenance of source information in a distributed authoring environment. The HyTime ilink architectural form provides the mechanism for its power, and the standard ensures that the valuable part of your data—the content—remains accessible where and when it is needed. |
Acknowledgments |
|
| U.S. Navy | Antech services are provided to the U.S. Navy under contract number N00140-94-C-BD34. |
| Darlene Janiszewski | The Metafile for Interactive Documents and the HyMID software were developed with Navy R&D resources. The Project Manager is Darlene Janiszewski, NAWCAD St. Inigoes; B-222 Villa Road, St. Inigoes, MD 20684-0010 Tel: (301) 862-8429 Fax: (301) 862-8488 E-mail: djaniszews@ietm.nawcsti.navy.mil |
| SGML SGML Architecture Steven R. Newcomb | Concepts regarding the application of SGML Architectures to MID were conceived by Steven Newcomb, TechnoTeacher, Inc. |
| Relationship | Relationship element design: MID Design Team, 1995. |
| Implementation of the HyMID reader was the primary responsibility of the following people: |
| Rob Groat |
| Mark Drissel |
| Peter J. Newcomb |
| Perry Rapp |
 |
| Charles F. Goldfarb - The HyTime Technical Corrigendum - Part 1 | Table of contents | Indexes | Eliot Kimber - Property Sets and Groves | |||