I've Got an SGML Database - Why do I need HyTime?   Table of contents   Indexes   Implementing a viable architecture for standardized Intelligent Graphics
 

Graphical Hotspot Definition - A Common ATA/AECMA Approach
 Dave   Cruikshank
  Associate Technical Fellow
  The Boeing Company  PO Box 3707 M/S 2L-17
Seattle   Washington  98124  USA
Phone: +1 206 544 8876
Fax: +1 206 544 9878
Email: david.w.cruikshank@boeing.com
 
Biographical notice:
 
Dave is an Associate Technical Fellow with The Boeing Company in the area of graphics and digital data interchange. He has several years of experience with SGML  (Standard Generalized Markup Language) and CGM  (Computer Graphics Metafile) interchange. He is currently the co-chair of the ATA  (Air Transport Association) Graphics Working Group and has led projects within Boeing to convert maintenance information to SGML compliant with the ATA interchange DTD's  (Document Type Definition) . He is the technical architect of the ATA intelligent graphics model.
DaimlerChrysler Aerospace
 Germany  
 Munich 
Zimmermann, Peter
 		Peter   Zimmermann
  Chief Advisor for Information Technology Logistics
  DaimlerChrysler Aerospace  PO Box 80 11 60
Munich   Germany  D-81663
Phone: +49 89 607 21738
Fax: +49 89 607 21875
Email: Peter.Zimmermann@m.dasa.de
 
Biographical notice:
 
Peter has several years of experience in text and image processing systems within DaimlerChrysler Aerospace. He is the advisor of the application and adoption of new information processing technologies. He is a member of the AECMA  (Association Europeane des Constructeurs de Materiel Aerospatiale) Electronic Publication Working Group and is their representative to the ATA Graphics Working Group. He was to first to propose and collaborative effort between the industries to have a common intelligent graphics implementation model.
 
ABSTRACT:
 WebCGM 
 XLink 
XML companion file
 XPointer 
graphical object
 intelligent graphics 
 
The ATA Graphics Working Group and the AECMA Electronic Publication Working Group have been working on a common approach to an external file format to satisfy navigation requirements for intelligent graphics. The authors will describe and compare the ATA intelligent graphics model with the WebCGM intelligent graphics model and outline a proposal for the use of XML  (eXtensible Markup Language) linking techniques to define and execute links between graphics and other graphics or text information. The proposal defines graphical objects using XPointers and hotspots using an Xlink mechanism. An  XML companion file associated with a CGM Version 4 interchange file will be presented, along with examples and potential future extensions.
 

Introduction
 

Purpose
 
The purpose of this paper is to introduce the concept of using XML companion files to support navigation in intelligent graphics. The concepts presented in this paper are an initial attempt to design a model for capturing metadata associated with an object within an intelligent graphic and making the metadata accessible to non-graphical applications. XML was chosen as the format for this model because of the potential of applications that may be able to deal with XML data.
 

Definitions
  Definitions
Term Definitions:
Definition
Graphical primitive
A basic drawing element which defines the geometry and its presentation. Examples are:
  •  Simple generic drawing primitive such as polylines, polygons, and sets of these.
  •  Specialized primitives such as rectangles, circles, ellipses, circular arcs, and elliptical arcs.
  •  Graphical text primitives such as restricted text and append text.
  •  Curves such as cubic, polybezier elements, non-uniform rational b-splines, and hyperbolic and parabolic arcs.
  •  Raster elements such as cell and tile arrays in uncompressed or compressed (CCITT4 or JPEG) format.
Graphical primitives normally have rendering details or properties associated with them such as line (type, width, color, etc.) and fill (solid color, hatch, pattern, etc.) attributes where appropriate.
Graphics metafile
A graphics metafile, in general, consists of one picture which in turn is generally composed of graphical primitives and their associated attributes.
Graphical object
An addressable logical unit within a picture which groups graphical primitives and/or graphical objects including the graphics metafile. This definition allows the creation of a hierarchical structure or a collection of graphical objects. These graphical objects are realized in CGM Version 4 by Application Structures.
(Graphical) hotspot
A (graphical) object which participates in a link, a so-called resource in Xlink terminology.
 XML companion file
An XML instance closely connected to the CGM Version 4 metafile which contains non-graphical meta-data of the graphical objects.
XLink file
An XML instance which contains the linking elements and the hotspot definitions (Xlink locators).
 

Background
 
The ATA Graphics Working Group has been developing specifications for intelligent graphics since 1989. In 1993, an intelligent graphic functional specification (IGFUNQREQ) was published in approved status by the ATA as part of the digital data specifications. At that time work began on an intelligent interchange specification (IGEXCHANGE). IGEXCHANGE is a profile of CGM Version 4 elements and is written as an extension to the ATA graphics interchange specification (GREXCHANGE), which is an application profile of the  CGM standard. A structure model for illustrations in the air transport industry was developed. A simplified version of that model is present in the following figure.

 ATA Intelligent Graphics Model
  
 
The content model of the ATA intelligent illustrations captures locator views, detail views, and text realized within paragraphs. Callouts (the linking mechanism) are attached to various elements in the hierarchy. The hierarchical model was chosen to model illustrations because it enabled the development of an SGML  DTD  (Document Type Definition) fragment to describe the graphic. The concept of a companion file has been discussed several times in the development of IGEXCHANGE. The current ATA model allows for an SGML fragment to be carried along with the  CGM file in interchange to capture the metadata associated with the illustration. This construct was not well defined and was left up to implementations for definition.
 
The GREXCHANGE profile has since enabled CGM Version 4 elements through the use of a simple recursive graphical object application structure with hotspot region and name attributes associated with them to facilitate the migration toward the full intelligent graphics model.
 
In 1998, a representative from AECMA approached the ATA Graphics Working Group with a proposal to capture the metadata in a specifically defined XML format. The ATA and AECMA working groups have been collaborating on a common format for the companion file since that time
 
The following presentation is a result of that work.
 

 ATA and WebCGM Profiles
 
In 1998 a consortium of vendors and users of CGM technology was formed, CGM Open. The first item on the technical agenda for that consortium was the development of a CGM profile for web applications. WebCGM was developed using the ATA GREXCANGE  CGM profile as a baseline. WebCGM was design as a subset of the CGM elements allowed and a superset of the linking functionality to support web addressing. The structure charts for WebCGM is illustrated by the following figure.

WebCGM Intelligent Graphics Model
  
 
In reality, the WebCGM intelligent graphics functionality is beyond GREXCHANGE, but not as rigorous as IGEXCHANGE. Within the ATA , it is expected that many of the linking constructs of WebCGM will be implemented in IGEXCHANGE as the industry looks forward to web delivery. WebCGM has recently been designated as an Approved Proposal within the W3C  (World Wide Web Consortium)
 
The conceptual model that follows is defined in general terms so that it could be applied to intelligent graphics within the GREXCHANGE, IGEXCHANGE, or WebCGM models.
 

Concepts
 

Requirements
 
The concepts are based on the following requirements and assumptions:
  •  Graphical and non-graphical information (illustrated documents) will in future be used in hyperlinked electronic form.
  •  Graphics ideally contain only graphical information, i.e. the CGM file contains only graphical primitives and associated geometrical information such as line and fill attributes. These primitives are grouped to logical units called graphical objects (grobject). The main reasons for this requirement are:
    1.  Non-graphical information (meta-data) about graphical objects can be easier maintained outside the graphics tool in an XML environment.
    2.  A decoupling of data and meta-data allows more flexibility in enriching the information about graphical objects.
    3.  Query functions, navigation, and data analysis may be easier to implement.
  •  The logical structure within graphics shall be made exposed. This allows the reuse of, not only the graphic as a whole, but also his pieces, the graphical objects.
  •  It shall be possible that graphical objects belonging to different graphics can participate in common links.
  •  A graphical object may participate in more than one link with different behavior.
  •  Multidirectional links within a graphic, between graphics, and between graphics and text shall be possible.
The following outline of the concept is only a first step in an effort to satisfy these requirements. More details have to be worked out, especially concerning the link management and the user interface.
 

Conceptual model
 
An overview of the concepts is illustrated by the following figure:

Conceptual outline
  
 
An intelligent graphic is composed of the CGM file and its associated XML companion file as indicated in the conceptual outline for sheet 1 and sheet 2 of the entity Figure. Within a CGM picture, groups of graphical primitives can be defined adding structure to the graphic. These groups are called graphical objects and may be assembled or nested to build up a hierarchical structure or collection of graphical objects. Each assembly or collection is again considered to be a graphical object. A graphical object must have a unique identifier within the graphic for addressing. In this model, the identifier and optional hotspot region information are the only explicit non-graphical properties of a graphical object within the CGM file and the identifier is replicated in the XML companion file.
 
The XML companion file contains all other non-graphical properties of graphical objects and allows addressing from the outside world. This explicit separation of graphical and non-graphical information (metadata) has the implication that hybrid or closely connected graphic and XML editors and viewers are required. This connection may be realized using powerful API's.
 
In order to get most flexibility with hyperlinking and navigation, the linking elements and the hotspots (locators) are defined in a separate XML file, external to text and graphics. This implies that only extended, out-of-line Xlinks are to be used. The looming problem of link management and proper event signaling on link traversal, as well as the definition of a user interface, are out of the scope of this paper and are left as a exercise for the ambitious implementor.
 

Addressing graphical objects
 

Application structures
 
Graphical objects are realized in the CGM file by the use of Version 4 Application Structures (APS). There is only one generic object called "grobject". This generic object may be typed by an attribute in the XML companion file to serve specific needs. Apart from the mandatory unique identifier (a parameter of the Begin APS element), the only allowed additional attribute of a graphical object is an optional "region". This attribute defines a spatial region associated with an APS for picking and highlighting purposes during navigation.
 
The content model of an APS expressed as an XML DTD fragment is as follows, where "gdata" stands for graphical content or those primitives that make up the graphical object:
  
<!ELEMENT grobject (grobject | gdata)* >
<!ATTLIST grobject
id      ID      #REQUIRED
region  CDATA   #IMPLIED >

<!ELEMENT gdata	   EMPTY >
 

Xpointers
 
The basic form of address chosen here is a URI  (Uniform Resource Identifier) The most important URI form used today is an extended URL  (Uniform Resource Locator) . The W3C Xpointer working draft allows far more general addressing schemes for objects.
 
An example URI for addressing a CGM file named "atacgm" and located in an area on the Boeing web site might look like:
 
http://www.boeing.com/cgm/atacgm.cgm
 
The graphical objects of the CGM file are addressed via the XML companion file using the  URI fragment identifier (#) followed by the grobject id. An example for addressing a graphical object with the identifier "grobj01" within the above CGM file might look as follows, where the string "id(grobj01)" is called the location term:
 
http://www.boeing.com/cgm/atacgm.xml#id(grobj01)
 
For compatibility reasons, a common ATA / AECMA graphics addressing scheme using an SGML entity still needs to be developed. This entity is called GNBR  (Graphic NumBeR) within ATA and ICN  (Illustration Control Number) within AECMA. It is defined as a separate attribute of the graphic element in the XML companion file and as a separate attribute in the hotspot definition (see below). In circumstances where the GNBR / ICN is unique, it allows the addressing of a graphical object by this entity combined with the grobject id.
 

The XML companion file
 
The XML  DTD fragment for the content model of the companion file is specified as follows:
  
<!ELEMENT   graphic      (grobject)* >
<!ATTLIST   graphic
graphicid    ENTITY    #REQUIRED
linkURI      CDATA     #REQUIRED >

<!ELEMENT   grobject     (gdata)* >
<!ATTLIST  grobject
id           ID        #REQUIRED
type         CDATA     #IMPLIED
name         CDATA     #IMPLIED
descript     CDATA     #IMPLIED >

<!ELEMENT  gdata        EMPTY >
 
The graphic element is the root element and contains zero or more graphical objects. These in turn are composed of zero or more gdata elements where gdata stands for graphical data/primitives. Two mandatory attributes are assigned to the graphic element. The graphicid entity shall contain the ATA  GNBR or AECMA  ICN as mentioned above. The second attribute linkURI shall contain the URI of the CGM file
 
The grobject element has the mandatory attribute id which is the unique identifier of the graphical object within the graphic. The optional type attribute may be used to specify a graphical object further. Examples for use within ATA might be the value "detail" or "callout". The optional attributes name and descript may be used to define a common name and a descriptional string for the graphical object.
 

(Graphical) hotspots
 
A graphical hotspot is defined as a graphical object which participates in a link. The standard Xlink set of locator parameters have been applied to the hotspot element named "hspot". In addition, the attribute refgraphic has been appended to hold the ATA  GNBR or AECMA  ICN entity. The XML  DTD fragment for (graphical) hotspots is as follows:
  
<!ELEMENT    hspot    EMPTY >
<!ATTLIST    hspot
xml:link   CDATA  #FIXED  "locator"
href       CDATA  #REQUIRED
refgraphic ENTITY #IMPLIED
role       CDATA  #IMPLIED
title      CDATA  #IMPLIED
show    (embed | replace | new)  "new"
actuate (auto | user)            "user"
behavior   CDATA  #IMPLIED >
 
The optional attribute role may be used to indicate a specific role which the graphical hotspot plays when taking part in a specific link. The title attribute may be used to display, for example, a screentip when the graphical object is reached by link traversal. It should be noted that when using the refgraphic entity, href may contain the grobject id only. The behavior attribute might be used to predefine a specific behavior for the viewer such as for example say "highlight" in general or "blink" in specific.
 

The linking element
 
The linking element used here represents an extended, out-of-line Xlink. It is presumed that it resides together with the hotspots in an XML file separate from text and graphics. This approach has potential for the future, for example, when integrating multimedia. The role attribute might be used to indicate the kind of link such as "text to graphic".
  
<!ELEMENT    hsplink    (hspot)+ >
<!ATTLIST    hsplink
xml:link  CDATA   #FIXED     "extended"
inline    (true | false)
"false"
role      CDATA    #IMPLIED
title     CDATA    #IMPLIED
show   (embed | replace | new) "new"
actuate    (auto | user)       "user"
behavior  CDATA    #IMPLIED >
 
The linking element attributes title, role, actuate, and behavior may be inherited by the hspot subelements.
 

Examples
 
The three examples given below highlight the most often required links in the area of technical documentation. They address text elements only by means of a simple ID mechanism which is the most robust form of Xpointer with regard to changes in text. This concept however allows also the use of more general Xpointers for addressing things in text which have no ID.
 

Bidirectional link between text and graphic
 
The first example shows a link between one text element and one graphical object.
 
  •  The CGM filename shall be "atacgm1.cgm".
 
  •  The XML companion file named "atacgm1.xml" contains the following fragment:
  
<graphic graphicid="GNBR01" linkURI="atacgm1.cgm">
<grobject id="grobj01" name="part1"></grobject>/graphic>
 
  •  The XML text file named "atatext1.xml" shall contain the following:
  
...<pnr id="refpart1">Part No. 1</pnr>
is used to...
 
  •  The Xlink file named "hsplink1.xml" contains one of the following XML fragment instances:
  
<hsplink role="text-hspot" behavior="highlight">
<hspot href="id(grobj01)" refgraphic="GNBR01"
title="Part No. 1"></hspot>
<hspot href="atatext1.xml#id(refpart1)"></hspot></hsplink>
 
or
  
<hsplink role="text-hspot" behavior="highlight">
<hspot href="atacgm1.xml#id(grobj01)" title="Part
No. 1"></hspot>
 
The following figure illustrates this example:

Text/Graphic link example
  
 

Bidirectional link between two graphical objects contained in one graphic
 
This second example shows a link between two graphical objects which belong to the same CGM file.
 
  •  The CGM filename is again named "atacgm1.cgm".
 
  •  The XML companion file named "atacgm1.xml" contains:
  
<graphic graphicid="GNBR01" linkURI="atacgm1.cgm">
<grobject id="grobj01" name="part1"></grobject>
<grobject id="grobj02" name="part2"></grobject></graphic>
 
  •  The Xlink file named "hsplink2.xml" contains:
  
<hsplink role="hspot-hspot" show="embed" behavior="highlight">
<hspot href="id(grobj01)" refgraphic="GNBR01"
title="Part No. 1"></hspot>
<hspot href="atacgm1.xml#id(grobj02)" title="Part
No. 2"></hspot>
</hsplink>
 

Multi-directional link between text and graphic ( & graphic and graphic)
 
The third example shows the link involvement of a text element and two graphical objects which belong to two different CGM files.
 
  •  The two CGM files involved are named "atacgm1.cgm" and "atacgm2.cgm".
 
  •  The first XML companion file named "atacgm1.xml" contains:
  
<graphic graphicid="GNBR01" linkURI="atacgm1.cgm">
<grobject id="grobj01" name="part1"></grobject></graphic>
 
  •  The second XML companion file named "atacgm2.xml" contains:
  
<graphic graphicid="GNBR02" linkURI="atacgm2.cgm">
<grobject id="grobj01" name="part1"></grobject></graphic>
 
  •  The XML text file named "atatext1.xml" again contains the following fragment:
  
...<pnr id="refpart1">Part1</pnr> is used
to...
 
  •  The content of Xlink file named "hsplink3.xml" looks like:
  
<hsplink role="text-hspots">
<hspot href="atacgm1.xml#id(grobj01)" title="Part
No. 1"></hspot>
<hspot href="id(grobj01)" refgraphic="GNBR02"
title="Part No. 1"></hspot>
<hspot href="atatext1.xml#id(refpart1)"></hspot></hsplink>
 

Potential future extensions
 
  •  The concept of using an XML companion file is one step forward in integrating text and CGM graphics more closely. Activities have been started to investigate the application/extension of the DOM  (Document Object Model) in this area.
  •  Textual components are still widely used in graphics for annotations. An extension of the XML companion  DTD by required text elements and properly linking them to the geometrical primitives (including positioning attributes) would allow their improved use in queries and navigation across illustrated documents.
  •  The linking mechanism outlined in this paper might also be used for creating links to and from resources in other multimedia formats such as video, audio, animations, 3D/ VRML  (Virtual Reality Modeling Language) , and even simulations.
  •  A further integration step between the text and the graphics world would be to establish and manage links between the authoring and the illustration system in form of "used-on lists" for graphics and graphical objects.
  •  This integration may well be expanded to establish a link to the enterprise PDM  (Product Data Management) system for used-on lists relating parts and equipment, because technical illustrations are often derived from 3D engineering models. These models can be the single source for modifications of derived graphical information.
 

Conclusion
 
In order to be able to use the proposed extended, out-of-line link mechanism with the simplest, most robust ID form of Xpointer more generally, it is advised that a generic element "anchor" with a required id attribute is defined in the text DTD's.
 
The proposal of using an XML companion file outlined in this paper is only a first attempt to integrate  XML documents and CGM graphics more closely. A lot more detail work need to be carried out to realize it, especially in the areas of link management, link traversal and adequate user interface
 
However, the authors, in an attempt to design a common model across industries, hope that this concept will be widely implemented. The ATA Graphics Working Group will continue to work with AECMA and build this concept into the ATA intelligent graphics interchange model.
I've Got an SGML Database - Why do I need HyTime?   Table of contents   Indexes   Implementing a viable architecture for standardized Intelligent Graphics