Defining Reusable, Distributable Information Objects Using XML-Data Schemas   Table of contents   Indexes   Integrating product model and the documentation: A practical approach
 
 

Imposing Intelligence on Graphics: Using HyTime Hyperlinks with Non-SGML Data

 
W. Eliot   Kimber
  ISOGEN International

Email: eliot@isogen.com Web: www.isogen.com
 
Biographical notice:
 
W. Eliot Kimber
 
Eliot Kimber is a Senior Consulting SGML Engineer for ISOGEN International Corp. Eliot is a co-editor of the HyTime standard, ISO/IEC 10744, a founding member of the XML Working Group, and a member of the U.S. delegation to WG4, the ISO committee responsible for the development of the SGML family of standards.
 ITEDO Software  
Weidenbrueck, Deiter
 
Eliot is author of a forthcoming book on HyTime as part of the Charles F. Goldfarb Series on Open Information Management. Eliot has over 15 years experience within industrial-strength electronic publishing and generalized markup. Eliot speaks and writes frequently on the subject of SGML, HyTime, and other related topics.
 
Deiter   Weidenbrueck
  ITEDO Software

Email: Dieter@isodraw.de Web: www.isodraw.com
 
Biographical notice:
 
Dieter Weidenbrück
 
Dieter Weidenbrück is the founder and President of ITEDO Software GmbH in Germany, the manufacturer of the Technical Illustration package IsoDraw. In addition, he is the co-founder and Chairman of The IsoDraw Company in the United States. He is the primary architect of the IsoDraw software program. Dieter Weidenbrück has developed a considerable experience in the field of documentation standards and is actively participating in standardization efforts concerning technical illustration and especially CGM.
 
ABSTRACT:
 
This paper discusses the use of HyTime hyperlinks and generalized location addressing to create hyperlinks from objects in CGM vector graphics to other graphic objects and also to data within SGML documents, demonstrating the power of HyTime independent links to link together any data for which grove views can be provided. Topics discussed include:
  • HyTime's grove-based addressing model and how it generalizes all data access within a HyTime processing context
  • Providing groves for non-SGML data, in this case, CGM graphics
    • Why the IsoView API is well suited to HyTime integration
    • Defining a property set for IsoView graphics
    • Providing a "grove view" of the graphics
  • The HyTime-conforming markup approach for representing hyperlinks and addresses
  • The association of behavior and presentation styles with hyperlinks and their anchors and the implications thereof
 
Presentation includes demonstration of a working HyTime system that integrates a graphic viewer, IsoView, with a generic HyTime engine in order to enable creation, management, and use of the hyperlinks.
 
NOTE: While this demonstration includes the use of a specific product, IsoView, that product is being used only to demonstrate a general approach that any similar tool could (and we think, should) use. It just happens that IsoView was an able and convenient candidate for integration with the general-purpose PHyLIS HyTime engine developed by ISOGEN for experimental and educational purposes.
 
 

Introduction
 
One significant requirement presented by technical documentation is the ability to create sophisticated hyperlinks between components of structured graphics and SGML data and among components of structured graphics. By "structured graphics" we mean graphics for which the source form provides rich structures. Most structured graphics are vector graphic formats such as CGM and Windows metafile. Raster formats can also be structured if they allow multiple separate images or layers within a single graphic object, such as GIF or PNG.
 
Meeting this requirement poses a serious challenge: there is no consistent or standardized way, across different graphic formats, to represent hyperlinks or addresses. Even if new formats did provide such a mechanism, old ones do not. About the best you can expect is a way to embed pointers within structured graphics. For example, CGM level four lets you add private extensions, which can be used for embedding links or pointers, but these extensions are, by definition, non-standard. In any case, no such mechanisms provide the same degree of generality or completeness that HyTime (or XLink) provide for representing hyperlinks and addresses. Even if a given graphic format or vendor-supplied editor or browser provides a way to point out of or in to the graphic, that mechanism is only usable for those graphics.
 
A more complete solution should be applicable to any graphic format and independent of specific browsers or editors or at least easily replicated with different software. It should also be insensitive to whether the hyperlinks are between SGML data and graphic components or among graphics components in the same or different graphics: i.e., the linking and addressing mechanism must be insensitive to the nature and source form of the data, regardless of what it might be. While this demonstration uses structured graphics as the non-SGML target of links, the same principles apply to data of all types.
 
The HyTime architecture provides such a solution. It provides a general model for representing hyperlinks that is insensitive to the type of data objects that are linked together. It provides a robust addressing mechanism that is insensitive to the data type being addressed. All it depends on is the existence of software that can provide a view of the data to be linked that is defined in terms of HyTime's unifying abstract data representation, "groves". Such software is not difficult to build, as the system described here demonstrates.
 
This paper describes a demonstration of an implementation of these general facilities of HyTime. The demonstration is in the form of a Visual Basic application that provides a general HyTime support layer (engine) to which an off-the-shelf CGM viewer has been integrated by providing a "grove view" of the CGM viewer's private API. Using this software, authors can create SGML documents that include hyperlinks to and from components of CGM graphics. The CGM viewer provides the hyperlink interaction support needed to enable traversal of hyperlinks from graphics. The HyTime engine provides the hyperlink interaction supported needed to enable traversal of hyperlinks from SGML documents.
 
We first discuss how the HyTime engine works generally and then discuss how the CGM viewer is integrated with it through a grove constructor. Finally, we provide sample documents that demonstrate the ability to create hyperlinks to and from graphic components.
 
NOTE: The PHyLIS package, which forms the core of the demonstration, is available for downloading from the ISOGEN Web site, www.isogen.com.
 
 

HyTime Engine Implementation Approach
 
The most general possible approach to implementing HyTime is by the creation of a grove-based HyTime engine, that is, a HyTime engine that operates on and manages literal groves. In such a system, different data formats are managed through grove constructors that construct groves managed by the HyTime engine (or by a more general grove management layer used by the HyTime engine).
 
 

Groves and Grove Constructors
 
A grove is nothing more than an "in-memory" data set that conforms to the general data model defined by the HyTime standard. A grove consists of nodes that have properties. The properties of a node may be primitive properties, such as strings or numbers, or they may be lists of nodes. A grove can be viewed as a flat list of nodes, as a tree, or as a directed graph of nodes. Technically, a grove is a directed graph. Every grove has exactly one root node. Nodes in one grove may point to nodes in other groves. The nodes in a grove have defined types. Each node type defines a set of named properties. Nodes are said to "exhibit" properties.
 
Groves are said to be "constructed" by grove constructors. A grove constructor is a software component that constructs a grove. There are two types of grove: primary and auxiliary. Primary groves are constructed from source data, such as SGML documents or graphic files. Auxiliary groves are constructed by processing other groves. Thus, a primary grove constructor is a software component that takes as input source data and produces as output a grove. An auxiliary grove constructor takes as input one more groves and produces as output a new grove. The grove constructor software embodies the grove construction process for a given data type.
 
The node classes and their properties for a given grove are defined in a "property set", which is nothing more than an object schema for a given grove type. The grove produced by a grove constructor must conform to a property set. Note that the property set for a grove does not define how the grove is to be constructed from a particular input--it only says what the node classes and properties are and what the allowed relationships among node types are. The definition of how to construct groves for a particular data notation is a separate specification. It may be defined purely in the software of the grove constructor or it may be defined in a grove construction definition document. Property sets are defined by property set definition documents, which are SGML documents that conform to the property set definition architecture defined in annex A1 of ISO/IEC 10744.
 
It should be clear that, given a property set and a grove construction algorithm, groves can be constructed from any kind of data. All it requires is defining the property set and writing the necessary grove construction software. In practice, most grove construction software will simply be layers on top of the data access APIs provided by existing software. For example, the SGML grove constructor provided by the SP parser is a layer on top of SP's base API. By the same token, the IsoView grove constructor is a layer of software on top of IsoView's API for accessing the graphics it displays.
 
All HyTime location addressing is defined in terms of addressing nodes in groves. This means that HyTime hyperlinks can link together any nodes in any groves. Given that it is possible to construct groves from any kind of data (or, more accurately, it is possible to create grove constructors for any kind of data) then it follows that HyTime hyperlinks and addresses can be used to link together objects for any kinds of data. All that is required is a generalized software layer that can manage groves constructed by a variety of grove constructors.
 
What this really means is that the way that different kinds of data and their supporting software are integrated with fully-integrated HyTime engines is through a general grove construction and access API. Any piece of software that can construct a grove or accept events applied against grove nodes can interoperate with the general HyTime engine without the need to know anything about any of the other groves in the system.
 
 

Digression 1: HyTime Hyperlink Concepts
 
The HyTime architecture defines a general structure for hyperlinks. A hyperlink represents an instance of a typed relationship (the link type ) among two or more anchors . An anchor is a list of one or more grove nodes. Each anchor of a hyperlink has a defined role within the relationship represented by hyperlink. The nodes that make up an anchor of a hyperlink are the anchor members for the anchor.
 
The members of a given anchor are determined by resolving the location addresses associated with a given hyperlink anchor using the hyperlink and location address representation syntax defined by the HyTime architecture. The form of addressing used to address the members of an anchor is irrelevant to the meaning of the link--all that's required is that the location addresses return nodes in groves.
 
This structure as several important implications. The first is that any node in any grove may be a member of one or more anchors of one or more hyperlinks. The second is that hyperlinks impose additional properties onto nodes that are anchor members, at a minimum, the anchor role name of the anchor the node is a member of and the link type of the hyperlink the anchor is a member of. There may be additional link-related properties, such as the rules for what traversal actions are allowed for particular anchor members. Applications may add their own properties on top of those defined by the HyTime architecture.
 
Another implication is that HyTime-aware browsers and editors must have an awareness of the link-related properties of anchor member nodes as well as user interfaces and APIs for taking advantage of those properties.
 
The information about hyperlinks and the location addresses used to address their members is maintained by a HyTime engine in the form of the "HyTime semantic grove", which is an auxiliary grove constructed by the HyTime engine by processing all of the groves it has been asked to examine for a particular processing session.
 
 

Digression 2: HyTime Location Addressing Concepts
 
The HyTime architecture defines a general facility for doing location addressing. This facility is defined in terms of the grove formalism, namely that all location addresses operate on groves, meaning that all location addresses apply to groves and address nodes in groves.
 
The HyTime architecture defines a syntax for doing location addressing. It also allows the use of any other syntaxes for which the result of resolving them can be defined in terms of nodes in groves (which is any syntax, given that groves can be usefully constructed from any kind of data).
 
Because the HyTime architecture defines a syntax for doing location addressing, it means that there are two classes of location addresses: HyTime-defined and "queries", that is, addresses in a syntax not defined by the HyTime architecture. One key advantage of HyTime-defined location addresses is interoperability because they are in a syntax defined in an International Standard. While queries (non-HyTime-defined location addresses) may be functionally equivalent to HyTime location addresses, they do not necessarily have the same level of interoperability that HyTime-defined location addresses do. Of course, this is not to say that there might not be a query notation that is at least as interoperable as HyTime location addresses. It does, mean, however, that queries that are not themselves defined by standards will almost certainly not be as interoperable as addressing methods defined by standards.
 
In particular, location address query notations defined for use with specific browsers, editors, or retrieval systems, will not be as interoperable as standardized methods.
 
This suggests that, as a matter of general principle, that it is better practice to enable the use of HyTime-defined location addressing methods for all location addressing. The goal of this demonstration is to do exactly that.
 
Note that there do exist standards that provide grove-based location addressing syntaxes that are or may soon be comparable to HyTime in terms of interoperability. The most prominent of these are the Standard Document Query Language (SDQL), defined by the DSSSL Standard (ISO/IEC 10179), and XML Xpointers, defined by the World Wide Web Consortium (W3C). The Standard Document Query Language is explicitly defined in terms of operations on groves and the Xpointer language can be without ambiguity.
 
 

Division of Labor
 
The general grove model and the HyTime hyperlink design suggests a general division of labor in a fully-generalized HyTime system: the HyTime engine manages the relationships (links and attendant addresses) among nodes in groves, grove constructors provide the groves, and grove renderers provide useful views of groves. This organization is shown in .

 
Relationship of Grove Manager to Grove Constructors and Grove Renderers

 
 
To support hyperlinking, a grove renderer must accept messages to the effect that some nodes in the grove it is rendering are members of anchors of hyperlinks. It must then provide some form of user interface that enables traversal from the anchor nodes. When a user selects a node for traversal, the grove renderer must communicate that fact back to the HyTime engine, which then informs the renderers of the groves that contain the nodes in the other anchors of the link that they have been traversed to. The ideal renderer also provides facilities for defining the presentation style or behavior of nodes based solely on their membership in anchors with particular roles in links of particular types.
 
Thus, the HyTime engine maintains knowledge of the hyperlinks and what they relate, while the grove renderers provide the user interfaces to enable presentation of and traversal to and from anchor nodes. The HyTime engine doesn't care what kind of data the different groves were constructed from. Each grove renderer doesn't care what kind of data the other groves in the system were constructed from. Any-to-any linking is enabled through a general grove construction/rendition paradigm. All HyTime semantics and processing are generalized in terms of groves.
 
Note that how groves are actually implemented under the covers is up to the implementers of the HyTime engine. There are any number of ways to do it. For the demonstration developed for this paper, the grove implementation is very literal, which makes it easy to implement and explain, but does not take advantage of any number of optimizations that would be needed for production-quality, large-scale implementations.
 
 

PHyLIS Grove Support
 
The HyTime engine used here is called PHyLIS (Personal HyTime Link Information System). It is a system of ActiveX components developed with Visual Basic. The PHyLIS system was developed in spare time between December 1997 and May 1998. It represents a total of about two person-months of direct development effort. It does reflect about five years of prior HyTime implementation experience.
 
PHyLIS provides two interfaces, one for grove constructors and one for grove renderers. It also provides hyperlink and address management facilities through the HyTime semantic grove constructor.
 
Through the PHyLIS grove construction interface, any ActiveX component that implements the interface can construct groves that are then managed by PHyLIS. Through the grove renderer interface, any ActiveX component that implements the interface can render groves managed by PHyLIS and participate in interactive hyperlinking to and from nodes in the rendered groves.
 
PHyLIS is itself an ActiveX component so that it can be used as a service by more specialized applications.
 
PHyLIS includes a built-in grove constructor for SGML and XML documents (using the groveoa ActiveX component provided as part of James Clark's Jade package). Other SGML or XML grove constructors could be integrated with PHyLIS using the generic grove constructor interface. However, PHyLIS' internal grove representation is intentionally unoptimized, so using it to manage groves of the size and complexity needed for SGML documents would result in poor performance. The SGML grove provided by the groveoa.dll is an optimized grove. PHyLIS' grove implementation is intentionally not optimized, which makes it more useful as an educational tool and makes implementation easier. The grove representation could be optimized without affecting the interfaces exposed by PHyLIS.
 
 

IsoView Grove Constructor and Grove Renderer
 
In order to enable hyperlinking to and from components of structured graphics, there must be both a grove constructor for the structured graphics and a grove renderer for the graphic groves. The IsoView viewer is used as the basis for both of these in this demonstration. Obviously, other similarly-featured software components could be used to build equivalent grove constructors and renderers. We chose IsoView because it was already very close to what was needed for this demonstration so it made an easy integration target.
 
The IsoView grove constructor is a thin layer of VisualBasic code that uses IsoView's built-in API to reflect the CGM objects exposed by IsoView as a grove. The IsoView grove conforms to the IsoView property set (as opposed to a property set for CGM graphics, which has yet to be defined at the time of writing). The IsoView property set is much simpler than the property set needed for the complete representation of CGM graphics. The IsoView API exposes only a fraction of the total sophistication of CGM structures.
 
The IsoView grove renderer is likewise a thin layer of Visual Basic code that uses IsoView's built-in "hot spot" functions to identify and distinguish those graphic objects that are members of link anchors, to capture traversal actions from the graphic, and to respond to traversal actions to the graphic.
 
Both the grove constructor and renderer use the IsoView viewer as an ActiveX component. This code demonstrates how off-the-shelf tools can be integrated into a larger grove-based system, such as PHyLIS.
 
 

Grove Representation of The IsoView API
 
The IsoView API primarily serves to expose two kinds of object: named graphic objects and named "viewports". A viewport is simply a set of presentation parameters for a graphic, such as the scaling factor and position with the graphic. Named graphic objects can be defined as "hot spots" during authoring, meaning that the IsoView browser will both provide a distinct presentation style for those objects and intercept mouse actions over those objects. The IsoView API provides both the ability to navigate to named objects or views and to intercept and respond to mouse actions applied to specific objects. This is all you need to enable the construction of groves and the rendition, with hyperlinking, of the groves.
 
The property set for IsoView graphics is fairly simple. It defines the following node classes:
IsoView root
 
The root of an IsoView grove. It serves to hold a pointer to the root graphic object of the graphic. It also provides a name space of named nodes within the graphic (analogous to the "elements" property of the SGML document grove, which is the name space of elements with IDs) and a name space of named view ports.
graphic object
 
A graphic object within an IsoView-rendered graphic. It has one property, which is its unique ID within the graphic.
viewport
 
A named view port. It has one property, which is its name.
 
This property set (and therefore groves that conform to it) reflects all the information that IsoView exposes through its API, which is all the information available to construct IsoView groves.
 
The actual IsoView property set is provided as an appendix to this paper.
 
 

Hyperlinking to IsoView Grove Nodes
 
To create hyperlinks to and from graphic components you must be able to address the grove nodes that represent the components. In the case of IsoView groves, the normal form of address would be by reference to the unique IDs of graphic objects or viewports. Because a grove can always be viewed as a tree, it is also possible to use tree-based addressing to address graphic components, although this is probably less useful in practical terms, in part because the order of nodes in the constructed grove may not be knowable or apparent to document authors. For this demonstration, all addresses use name-based addressing.
 
The HyTime architecture provides a generalized name-space addressing element, name-space location address (nmsploc). A name-space location address can address nodes by name in any name space in any grove. The IsoView grove provides two name spaces, one for named graphic objects, the other for viewports (which always have names).
 
A name-space address consists of three parts: a pointer to the node that exhibits the name space, the name of the name space, and the names of the nodes in that name space to be addressed. In the case of IsoView groves, the node that exhibits the names spaces is the IsoView root node, which you can address by naming the entity from which the IsoView grove is constructed (using the implied location source rules of HyTime). The name space name is either "objects" or "viewprts".
 
A specialized form of name-space location address element could be declared like so (assume that these declarations are part of the file "mydoc.dtd"):
 
<!-- Elements for addressing graphic objects and viewports
     in IsoView groves.
  -->
<!ELEMENT IsoView-LocationAddress
  -- Specialized form of HyTime name-space location address
     for addressing graphic objects or viewports in IsoView
     graphics. --

  -- Content of element is name or names of objects or
     viewports. --
  - -
  (#PCDATA)
>
<!ATTLIST IsoView-LocationAddress
   ID
     ID
     #REQUIRED
   IsoView-Graphic -- Entity that contains the graphic from
                      which grove is constructed. --
     ENTITY
     #REQUIRED
   name-space      -- Name space property in which named object exists --
     (objects |
      viewprts)
     objects
   HyTime
     NAME
     #FIXED "nmsploc" -- Derived from name-space location address --
   HyNames         -- Map local attribute names to HyTime-defined names --
     CDATA
     #FIXED "locsrc IsoView-Graphic namespc name-space">
 
The IsoView-LocationAddress element type is a specialized form of name-space location address (nmsploc) designed to be used specifically with IsoView groves. The IsoView-Graphic attribute points to the IsoView graphic that contains the objects or viewports to be addressed. It's value is an entity name and must be an entity with a notation that is associated with the IsoView grove constructor. As defined by the HyTime architecture, naming an entity as the location source or target of a location address element implies a reference to the grove constructed from the entity.
 
In this system, the IsoView-specific notation is called "IsoView". As currently implemented, the PHyLIS engine hard-codes the relationship between entities and grove constructors. The better implementation is to provide a registration mechanism by which notations are associated with grove constructors and grove renderers. The HyTime architecture does provide a general mechanism for explicitly associating an entity with a grove constructor, although PHyLIS does not yet support that mechanism.
 
The name-space attribute defines which type of object is being addressed. The allowed values are the names of the name-space properties of the IsoView node class defined in the IsoView property set.
 
The HyTime attribute indicates that the IsoView-LocationAddress element is derived from the HyTime-defined element form "nmsploc" (name-space location address). The HyNames attribute defines the mapping from the HyTime-defined attributes "locsrc" (location source) and "namespc" (name-space) to the corresponding local names "IsoView-Graphic" and "name-space".
 
A typical document that uses these element types is:
 
<!DOCTYPE MyDoc SYSTEM "mydoc.dtd" [
 <!NOTATION
    IsoView
    PUBLIC "+//isodraw.com//NOTATION IsoView CGM//EN"
 >
 <!ENTITY
    graphic-1
    SYSTEM "graph1.cgm"
    NDATA IsoView
 >
]>
<MyDoc>
 ...
<IsoView-LocationAddress
  id="graphic-object-1"
  name-space="objects"
  IsoView-Graphic="graphic-1">object-abc
</IsoView-LocationAddress>
 ...
</MyDoc>
 
This name-space location address points to the graphic object node with the ID "object-abc" in the grove constructed from the IsoView entity "graphic-1".
 
The following examples use two hyperlink types: part-to-description and assembly-to-subassembly. The part-to-description link type relates parts in graphics to their description in a document. The assembly-to-subassembly link relates a picture of a subassembly to the assembly of which it is a component. For part-to-description links, two different forms are defined, a contextual form (Part-Description) and a completely independent form (Part-to-Description-Link). The Assembly-to-Subassembly link is represented by a single element type. All three element types are derived from the HyTime "hylink" (hyperlink) element form:
 
<!ELEMENT Part-Description
  -- Relates a part to its textual description --
  -- The Part-Description element contains the description --
  - -
  ANY -- For this example, the content is unimportant --
>
<!ATTLIST Part-Description
   HyTime
     NAME
     #FIXED "hylink"
   linktype
     NAME
     #FIXED "part-to-description"
   anchor-roles
     CDATA
     #FIXED "part #LIST description #LIST"
   anchor-constrataints
     CDATA
     #FIXED "required self"
   part        -- Reference to parts for which this element is the
                  description --
     IDREFS
     #REQUIRED
   HyNames
     CDATA
     #FIXED "anchrole anchor-roles anchcstr anchor-constraints">

<!ELEMENT Part-to-Description-Link
  -- Relates a part to its textual description. --
  -- Both anchors are explicitly addressed. --
  - O
  EMPTY
>
<!ATTLIST Part-to-Description-Link
   HyTime
     NAME
     #FIXED "hylink"
   linktype
     NAME
     #FIXED "part-to-description"
   anchor-roles
     CDATA
     #FIXED "part #LIST description #LIST"
   part        -- Reference to part --
     IDREFS
     #REQUIRED
   description -- Reference to description of the part --
     IDREFS
     #REQUIRED
   HyNames
     CDATA
     #FIXED "anchrole anchor-roles"
>

<!ELEMENT Assembly-to-Subassembly-Link
  -- Relates an assembly to a subassembly
  -- Both anchors are explicitly addressed. --
  - O
  EMPTY
>
<!ATTLIST Assembly-to-Subassembly-Link
   HyTime
     NAME
     #FIXED "hylink"
   linktype
     NAME
     #FIXED "assembly-to-subassembly"
   anchor-roles
     CDATA
     #FIXED "assembly #LIST subassembly #LIST"
   assembly    -- Reference to part --
     IDREFS
     #REQUIRED
   subassembly -- Reference to description of the part --
     IDREFS
     #REQUIRED
   HyNames
     CDATA
     #FIXED "anchrole anchor-roles"
>
 
The first example uses a Part-Description link to connect a description of a part to the drawing of the part within a graphic. This is a simple example of linking from a document to a graphic object.
 
<!DOCTYPE MyDoc SYSTEM "mydoc.dtd" [
 <!NOTATION
    IsoView
    PUBLIC "+//isodraw.com//NOTATION IsoView CGM//EN"
 >
 <!ENTITY graphic-1 SYSTEM "graph1.cgm" NDATA IsoView>
]>
<MyDoc>
 ...
<IsoView-LocationAddress
  id="graphic-object-1"
  name-space="objects"
  IsoView-Graphic="graphic-1">object-abc
</IsoView-LocationAddress>
 ...
<Part-Description
  part="graphic-object-1">
The Spacely Sprocket is....
</Part-Description>
  ...
</MyDoc>
 
The next example uses an Assembly-to-Subassembly link to create a hyperlink between two graphic objects:
 
<!DOCTYPE MyDoc SYSTEM "mydoc.dtd" [
 <!NOTATION
    IsoView
    PUBLIC "+//isodraw.com//NOTATION IsoView CGM//EN"
 >
 <!ENTITY graphic-1
    SYSTEM "graph1.cgm"
    NDATA IsoView
 >
]>
<MyDoc>
 ...
<IsoView-LocationAddress
  id="graphic-object-1"
  name-space="objects"
  IsoView-Graphic="graphic-1">object-abc
</IsoView-LocationAddress>
<IsoView-LocationAddress
  id="graphic-object-2"
  name-space="objects"
  IsoView-Graphic="graphic-1">object-def
</IsoView-LocationAddress>
 ...
<Assembly-to-Subassembly-Link
  assembly="graphic-object-1"
  subassembly="graphic-object-2">
 ...
</MyDoc>
 
Here, the assembly-to-subassembly-link element establishes a relationship between two graphic objects. These two graphic objects happen to be in the same graphic, but they could be in different graphics.
 
The last example uses the Part-to-Description-Link element to connect a graphic object to a separate description element:
 
<!DOCTYPE MyDoc SYSTEM "mydoc.dtd" [
 <!NOTATION
    IsoView
    PUBLIC "+//isodraw.com//NOTATION IsoView CGM//EN"
 >
 <!ENTITY graphic-1
    SYSTEM "graph1.cgm"
    NDATA IsoView
 >
]>
<MyDoc>
 ...
<IsoView-LocationAddress
  id="graphic-object-1"
  name-space="objects"
  IsoView-Graphic="graphic-1">object-abc
</IsoView-LocationAddress>
 ...
<Part-Description id="spacely-sprocket">
<part-name>Spacely Sprocket</part-name>
   ...
</Part-Description>
 ...
<Part-to-Description-Link
  part="graphic-object-1"
  description="spacely-sprocket">
 ...
</MyDoc>
 
Here, the graphic object addressed by the IsoView-LocationAddress element is linked to the Part-Description element.
 
Note that in all these examples, the only thing that changed from one example to the next is the location addresses used. The hyperlink elements are insensitive to the form of location address.
 
 

Conclusions
 
Given a generalized grove-based HyTime engine, it is relatively straightforward to integrate support for hyperlinking to and from a variety of data types without the need to do direct engine-to-renderor integration. The generalized HyTime support makes it possible to use standardized HyTime addressing methods rather than private queries to link to and from components of graphics (or any other data notation for which groves are constructed). The use of a component technology such as ActiveX is a good implementation fit for the grove model because it makes it easy to integrate new components into the system without disturbing existing components or requiring modification or re-linking of the core HyTime engine. In other words, the general grove-based approach naturally leads to a plug-in type implementation because it provides a general data model in terms of which all the components communicate.
 
 

Appendix A. IsoView Property Set Definition Document
 
 
<!DOCTYPE propset PUBLIC "ISO/IEC 10744:1997//DTD Property Set//EN" [
<![IGNORE[
  =============================================================
  IsoView Property Set

  Public ID: +//IDN isodraw.com//DOCUMENT IsoView Property Set//EN

  Version: 0.0

  Author: W. Eliot Kimber


  =============================================================
  ]]>
<!NOTATION IsoView PUBLIC "-//ISODraw//NOTATION IsoView Graphic//EN">
]>
<propset nsd=IsoView>

<classdef rcsnm=iviewrt appnm="IsoView root" conprop=docobj>
<desc>
The root of an IsoView grove.

<propdef rcsnm=docobj appnm="document object" nodelist subnode ac=grphobj>
<desc>
The root object of an IsoView graphic.
<note>
Analogous to the "docelem" property of the SGMLDoc object in the SGML
property set.

<propdef rcsnm=objects appnm="named objects" nmndlist irefnode ac=grphobj
         acnmprop="id">
<desc>
A named node list of graphic objects with names.
<note>
Analogous to the "elements" property in the SGML property set.

<propdef rcsnm=viewprts appnm="viewports" nmndlist subnode ac=viewport
         acnmprop=name>
<desc>
The viewports defined within a graphic.

</classdef>

<classdef rcsnm=grphobj appnm="graphic object" conprop=content>
<desc>
A graphic object within an IsoView graphic.

<propdef rcsnm=id string>
<desc>
The unique ID of the graphic object.

<propdef rcsnm=content nodelist subnode ac=grphobj>
<desc>
The child objects of this object

<propdef rcsnm=ishot appnm="is hotspot" boolean>
<desc>
Indicates whether or not the graphic object has been
identified as a hotspot.

</classdef>

<classdef rcsnm=viewport>
<desc>
A named viewport.

<propdef rcsnm=name string>
<desc>
The unique name of the viewport

</classdef>
Defining Reusable, Distributable Information Objects Using XML-Data Schemas   Table of contents   Indexes   Integrating product model and the documentation: A practical approach