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.
MID DTD HyTime Technical Corrigendum 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.
<- Architectural Form -> <- Ilink -> <- MID DTD -> Relationship The relationship conforms to the architecture for a HyTime ilink. 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 HyTime ilink. The pseudo-declaration in the MID DTD is an architectural form for relationship elements defined each MID instance. The generic identifier of the relationship 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:
<!ELEMENT relationship - O ( title,(%locs;)*) ><<!ATTLIST relationship HyTime NAME ilink id ID #IMPLIED relationshipName #CDATA #FIXED anchrole CDATA #FIXED "antecedent #AGG consequent #AGG" linkends IDREFS #REQUIRED extra NAMES #IMPLIED intra NAMES #IMPLIED endterms IDREFS #IMPLIED aggtrav NAMES agg MID NAME #FIXED relationship privTrav NAMES #IMPLIED traversal ( gosub | spawn | goto | undefined) spawn >
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 the relationship form pseudo-declaration.
<- Relationship -> <- Anchrole -> <- Linkend -> PrivTrav The privTrav contains none, one, or all of the anchrole names. Its purpose is to define a default traversal from none, all, or each linkend to another linkend within the relationship.
Gosub Goto Spawn <- Traversal -> The traversal semantic is governed by the traversal attribute. If traversal is set to be undefined, 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.
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 the Magneto Rotor, will be the focus of this example. With this limitation, a more complete view of the operation of the relationship element for implementing hyperlinking between text and graphic objects will be possible.
<- Hotspot -> <- Object -> <- Relationship Generic Identifier -> <- HotObjects -> <- Zonelist -> For the generator's interactive technical manual we create three elements in the MID instance (i.e., equipment, hotObjects, and zonelist) that are based on the relationship pseudo-declaration. The equipment relationship is used to identify the occurrences of an equipment component reference within specific contexts throughout the document. The equipment relationship will be used to locate other relevant information about a component by clicking on an occurrence of that component in text or graphics.
MID author <- Object -> <- Topic Map -> <- HotObjects -> <- CApH -> 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. The hotObjects 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 -> The zonelist 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.
<- Container -> <- InfoContainer -> <- Pane -> A MID infoContainer element is a fundamental building block of a MID instance that delimits a set of information an authors intends will be rendered together. Within an infoContainer, 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 -> <- Object -> <- HotObjects -> <- Pane -> <- SpecialText -> <- SGML -> A text pane can contain (via the defined SGML hierarchy) one or more occurrences of the element specialText, used in this case to identify an anchor for reference by the hotObjects relationship.
<infoContainer id=IgnitionCoilDesc>
<title>Ignition Coil Description</title>
<clientArea>
<pane>
<text>
<paragraph>Federal Stock Number: 5307-978-7078</paragraph>
<paragraph>Description: Ignition coil</paragraph>
<paragraph>Unit of Issue: ea</paragraph>
<paragraph>Quantity: 1</paragraph>
<paragraph>Manufacturer: Georgia Hardware Manufacturing</paragraph>
<paragraph>Click here for other
<specialText type=anchor id=hwIgnitionCoilLinks>
ignition coil
</specialText> references.</paragraph>
</text>
</pane>
</clientArea> </infoContainer><- Entity -> <- Notation -> Both graphics files and the named objects within the files are referenced by entities. For graphics files, a notation declaration is also required.
<!-- Notation and entity for external file * --><<!NOTATION SHG PUBLIC
"-//ISBN 0-7923-9432-1::Graphic Notation//NOTATION
Microsoft Segmented Hypermedia//EN"><<!ENTITY IPBIgnitionShg SYSTEM "Ignition.shg" NDATA SHG ><<<!-- Entity list of hotzones for the ignition system * --><<!ENTITY IgnitionCoilObj "hzIgnitionCoil"><<!ENTITY MagnetoRotorObj "hzMagnetoRotor">Docorsub <- Element -> <- Entity -> <- Nameloc -> For maximum flexibility in referencing the elements and entities that will be used in relationships, we add a layer of namelocs. During maintenance of information, authors are then free, for example, to move elements and entity declarations among files. The only requirement would be to change or add a docorsub attribute to the referencing nameloc.
<!-- Nameloc for infoContainer * --><<nameloc id=IgnitionCoilDescLoc> <nmlist element nobnames>IgnitionCoilDesc</nmlist></nameloc><<<<!-- Nameloc for hotword in infoContainer * --><<nameloc id=hwIgnitionCoilLinksLoc> <nmlist element nobnames>hwIgnitionCoilLinks</nmlist></nameloc> CONSTRUCT Nameloc MENTION
<!-- Nameloc for graphic file * --><<nameloc id=IPBIgnitionShgLoc> <nmlist entity nobnames>IPBIgnitionShg</nmlist></nameloc><<!-- Nameloc for graphic hotzone * --><<nameloc id=hzIgnitionCoilLoc> <nmlist entity nobnames>IgnitionCoilObj</nmlist></nameloc><<!-- Nameloc for graphic hotzone in external file * --><<nameloc id=xhzMagnetoRotorLoc> <nmlist entity nobnames docorsub=parts> MagnetoRotorObj </nmlist><</nameloc> CONSTRUCT Nameloc MENTION
<- Aggregate -> <- Anchor -> <- Object -> <- HotObjects -> Linkends For some relationships, it is beneficial to use an aggregate link. By contrast, the equipment relationship uses a fixed number of linkends to enforce structure. Authors must select the most appropriate anchor of each type to reference. However, in the case of the hotObjects relationship, it is advantageous to leave the number of linkends open.
<- Aggregate -> <- Container -> <- Object -> Agglink <- HotObjects -> <- InfoContainer -> <- Linkend -> <- Nameloc -> Nmlist Recall that the hotObjects 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, the hotObjects element defines an aggregate (#agg) linkend. To take advantage of the aggregate, we use a nameloc with the aggloc attribute set, allowing multiple elements in the enclosed nmlist. As we have referred to all hotwords and hotzones using other nameloc elements, we can use a single nmlist to gather up all the occurrences of the topic, including any infoContainers that contain specific content for the topic. For this example, we will include the infoContainer IgnitionCoilDesc (shown previously) in an aggregate nameloc that includes other objects that are semantically related to it.
<!-- Nameloc referencing hotObjects for Ignition Coil * --><<nameloc id=IgnitionCoilLoc aggloc=aggloc> <nmlist element nobnames> hzIgnitionCoilLoc hwIgnitionCoilLoc hwIgnitionCoilLinksLoc IgnitionCoilDesc </nmlist><</nameloc> CONSTRUCT Nameloc MENTION
Another application for an aggregate nameloc is to identify the hotzones in a graphics file. The zonelist relationship needs to reference a variable number of zones for each graphic. It looks like this:
<!-- Nameloc referencing hotzones in the ignition.shg graphic * --><<nameloc id=IgnitionZones aggloc=aggloc> <nmlist element nobnames> hzIgnitionCoilLoc hzMagnetoRotorLoc </nmlist><</nameloc> CONSTRUCT Nameloc MENTION
The technical manual data is marked up with identifiers that assign names to infoContainers, graphics, and objects that are distributed throughout the data set. Each of them is a reusable data source accessible, among other means, by MID relationships. The relationship elements are declared as follows.
<- Container -> <- Relationship Generic Identifier -> <- Anchrole -> <- InfoContainer -> <- Nameloc -> The equipment linkends point to descriptive text, parts list, and illustrated parts breakdown (IPB) infoContainers, via namelocs. The anchroles may be used by MID browsers to list the optional paths that may be traversed by users.
<!ELEMENT equipment - O (title,(%locs;)*) ><<!ATTLIST equipment
HyTime NAME ilink
id ID #IMPLIED
relationshipName CDATA #FIXED "Equipment"
anchrole CDATA #FIXED "Descriptive_Info
Parts_List
IPB_Diagram"
linkends IDREFS #REQUIRED
extra NAMES #IMPLIED
intra NAMES #IMPLIED
endterms IDREFS #IMPLIED
aggtrav NAMES agg
MID NAME #FIXED relationship
privTrav NAMES #IMPLIED
traversal ( gosub | spawn | goto | undefined) goto
><- Hotspot -> <- Object -> <- Relationship Generic Identifier -> <- HotObjects -> The hotObjects 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 -> <- Object -> <- Anchrole -> <- Linkend -> Note that in the case of an aggregate linkend (such as is identified by the anchrole Objects #agg below), the application can't use the anchroles 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 destination anchor.
<!ELEMENT hotObjects - O (title,(%locs;)*) ><<!ATTLIST hotObjects
HyTime NAME ilink
id ID #IMPLIED
relationshipName CDATA #FIXED "Topic Links"
anchrole CDATA #FIXED "Topic
Objects #AGG"
linkends IDREFS #REQUIRED
extra NAMES #IMPLIED
intra NAMES #IMPLIED
endterms IDREFS #IMPLIED
aggtrav NAMES agg
MID NAME #FIXED relationship
privTrav NAMES #IMPLIED
traversal ( gosub | spawn | goto | undefined) spawn
><- Hotspot -> <- Relationship Generic Identifier -> <- Zonelist -> The zonelist 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 -> <- Object -> Extra <- HotObjects -> Intra <- 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. The hotObjects relationship determines what happens when a user clicks on a hotspot. To avoid confusion, we restrict the traversal to and from the anchors identified in the zonelist relationship by setting the extra and intra attributes. Traversal from shared anchors is determined solely by the hotObjects relationship.
Any Because both the extra and intra attributes carry the same values the rules apply to traversal regardless of how you arrived at the anchor. Any traversal is allowable from within containers, but only external traversals are allowed from any of the zones. Therefore, traversal from zones are restricted to only those defined in non-zonelist-type relationships.
<!ELEMENT zonelist - O (title,(%locs;)*) ><<!ATTLIST zonelist
HyTime NAME ilink
id ID #IMPLIED
relationshipName CDATA #FIXED "Zones"
anchrole CDATA #FIXED "container
zones #AGG"
linkends IDREFS #REQUIRED
extra NAMES #FIXED "A E"
intra NAMES #FIXED "A E"
endterms IDREFS #IMPLIED
aggtrav NAMES agg
MID NAME #FIXED relationship
traversal ( gosub | spawn | goto | undefined) spawn
>Recall that we have identified the following types of declarations in previous discussion.
<- Container -> <- InfoContainer -> <- SpecialText -> An infoContainer, which may have specialText 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:
<!NOTATION SHG PUBLIC
"-//ISBN 0-7923-9432-1::Graphic Notation//NOTATION
Microsoft Segmented Hypermedia//EN"><<<!ENTITY IPBIgnitionShg SYSTEM "Ignition.shg" NDATA SHG ><<<!ENTITY IgnitionCoilObj "hzIgnitionCoil">
<- Container -> <- InfoContainer -> <- Nameloc -> Namelocs for the infoContainer, the graphic, the hotwords, and the graphic hotzones:
<!-- Nameloc for infoContainer * --><<<nameloc id=IgnitionCoilDescLoc> <nmlist element nobnames>IgnitionCoilDesc</nmlist></nameloc><<<!-- Nameloc for graphic file * --><<nameloc id=IPBIgnitionShgLoc> <nmlist entity nobnames>IPBIgnitionShg</nmlist></nameloc><<<!-- Nameloc for hotword in infoContainer * --><<<nameloc id=hwIgnitionCoilLinksLoc> <nmlist element nobnames>hwIgnitionCoilLinks</nmlist></nameloc><<<!-- Nameloc for graphic hotzone * --><<nameloc id=hzIgnitionCoilLoc> <nmlist entity nobnames>IgnitionCoilObj</nmlist></nameloc>
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 example <- Relationship -> 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 files midair.mdf (the hub document) and midmag.msf (the external MID support file referenced from the MID hub document).
<!-- equipment relationship for the Ignition System * --><<equipment id=eqIgnition
linkends="IgnitionLoc PL-IgnitionLoc IPB-IgnitionLoc"
privTrav=Descriptive_Info
traversal=gosub>
<title>Ignition System</title><</equipment>
<- Container -> <- InfoContainer -> Figure 4. The equipment relationship points to infoContainers via namelocs
<!-- hotObject relationship for the Ignition Coil topics * --><<hotObject id=hotIgnitionCoil
linkends="IgnitionTopic IgnitionCoilLoc"
privTrav=Topic
traversal=gosub>
<title>Ignition Coil Index</title><</equipment>
<- Hotspot -> <- Object -> <- HotObjects -> 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
<- 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.
David W. Cooper This paper was prepared for HyTime 96 by David W. Cooper [ dwcooper@nando.net ]. Copyright ©1996 Antech Systems, Inc. All rights reserved.
<- 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
<- Steven R. Newcomb -> <- SGML Architecture -> <- SGML -> 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 Rob Groat (Booz Allen & Hamilton, Inc.) - Browser module
- Mark Drissel Mark Drissel (Computer Sciences Corporation) - Data Packager module
- Peter J. Newcomb Peter Newcomb (TechnoTeacher, Inc.) - HyMinder™ HyTime engine library
- Perry Rapp Perry Rapp (Computer Sciences Corporation) - MID Engine module