With the increased support for CGM version 4, the number of illustrations stored and distributed in this format has increased rapidly over the past years. The most predominant profiles are WebCGM and the ATA GREXCHANGE profile of the Air Transport Association. The CALS community references both profiles from within their MIL-D-28003B specification.

The various profiles all support the storage of metadata inside a CGM file using the "grobject" structure described at the end of this document. However, it is worthwhile to examine the storage of this metadata in more detail to take full advantage of using CGM files.

What is Metadata?

Essentially all non-graphical information stored inside a graphics file is considered as metadata. However, in this case I would recommend thinking about all information that you want to associate with a particular part of an illustration. This may be a simple hotspot and an ID, or it may be a very sophisticated list of information about a wire in a schematic diagram, e.g. diameter, voltages, test values etc.

Here we have to distinguish between different cases, depending on the profile you want to use:

WebCGM
WebCGM uses the "grobject" to store non-graphical information. It allows for the following attributes:

ATA GREXCHANGE
The ATA profile allows for an almost identical set of information:

id	the unique ID of the object
name	a non-unique name for the object
region	a clickable hotspot region
viewcontext	a target rectangle if the object is the target of a link operation
screentip	a screentip shown if the mouse is on top of the object
refLoc	a link specific to ATA

No specific profile
If you use CGM version 4 without a specific profile, anything can be stored inside the CGM file. However, this has the consequence that typically only products of a single vendor can handle the information as desired.

Neither WebCGM nor GREXCHANGE allow you to store additional information inside a CGM file, and for good reasons. Interoperability and reliability when exchanging data between products of different vendors is the most important goal for these profiles.

If you want to store additional information with your graphical objects, there are basically two ways. You can use CGM 4 without a profile and store your metadata using a proprietary DTD for graphical objects. This approach is supported by IsoDraw and IsoView, but not necessarily by other products.

The recommended alternative is to store the metadata outside of the CGM file in an XML or SGML companion file. This approach ensures compatibility with current and future CGM products.

The CGM file should contain only information that is directly related to the graphical content. Referring to the profiles this is
 

• id:  needed to identify the object uniquely
• name: needed to identify objects by common names, could also be outside of the CGM
• region: this is graphical content, coordinates and shapes
• viewcontext: this is a rectangle, also given in coordinates
  

For simple cases, also the screentip and the linkURI may be stored inside, all other attributes must be on the outside.

Let's look at two cases:

Case 1
Inside the CGM we have a grobject with the aforementioned attributes. We add a simple screentip indicating a part number to the object, e.g. "2376-A88". We have another object that we want to click to go to a web address, so we add a linkURI "http://www.itedo.com".

These are static attributes in a simple case, so they may easily be stored inside the CGM.

Case 2:
We have the same objects inside the CGM file. The problem is that we want to use the file in various language versions of our publication or IETM. So a simple screentip doesn't work, we need a way to supply a language-specific screentip at runtime.

The same problem arises if our link depends on the usage of the file, e.g. whether the file is used inside a parts catalog (link to the parts table), or inside a maintenance manual (link to the descriptive text).
In this case it is worth thinking about a companion file that contains the information needed at runtime.

So far we have discussed the allowed attributes of WebCGM and GREXCHANGE only. If we want to stay compliant and store additional information at the same time, there is no way around external storage.

Strategic considerations

If we limit the metadata inside the CGM file to what is really needed we can reap these benefits:

• The grobject and the mentioned attributes have been stabile for the past 5 years and will not change for a long time. This ensures compatibility with future CGM releases and products.
• Any metadata stored outside of the CGM file is much easier to be maintained. If an XML/SGML companion file is used, all known tools can be used to manipulate the data as needed.
• In a companion file, anything can be stored. There is no dependency on a vendor's particular CGM implementation.
• The AECMA (European Aeronautics Consortium) has introduced the concept of the XML companion file, which has been adopted in other areas of the industry as well.
  

At present, there is no specific schema or DTD for a CGM companion file, because the information to be stored varies too much.

In principle, you can build such an XML file as follows:
<cgmcompanion file="myCGMfile.cgm" .(other attributes)>
  <grobject
    id='myID1'
    screentipEng = 'my English screentip'
    screentipGer = 'mein deutscher Screentip'
    wireDia = '2.5 dia'
    link1 = '... some link'
    link2 = '... some other link'
    link3 = '... some third link'
  />
  <grobject  ... and so on for each object
    ...
  />
</cgmcompanion>

At runtime, the viewer will report the mouse event to the runtime environment using the ID of the grobject. A simple lookup suffices to find the right link for this object, if necessary, even context-dependant.

In most cases it will be sufficient to store the metadata inside the CGM file - as long as we are dealing with allowed attributes. However, there are a lot of cases where it is recommended to store links and attributes in separate files:

• if frequent changes occur to the attributes
• if access is needed to the attributes from other programs, e.g. to link text and graphics
• if files need to be maintained for a long time with frequent revisions
• if interoperability is important, e.g. if you don't want to depend on a particular vendor's implementation of CGM
• if attributes need to be stored with graphic objects that are not allowed in one of the CGM profiles, e.g. a wire diameter, a price, a test value or similar
• if you have simple cases now, but you smell that your requirements will become more sophisticated in the future

"Application structures" are used to define hotspots in CGM files. The 1995 Amendment 2 to ISO/IEC 8632:1992 added application structures to CGM and defined Version 4 as the latest version of CGM. Application structures allow the inclusion of non-graphic information in the file associated with various graphic elements. However, the amendment only specifies the syntax of an application structure without assigning any semantics to it. Here is an example of an application structure embracing a restricted text element shown in clear text encoding:

   BEGAPS 'callout1' 'grobject' STLIST;
   APSATTR 'name' "14 1 'Callout 123'";
   BEGAPSBODY;
   RESTRTEXT 7 4 216,246 final '123';
   ENDAPS;

The application structure begins with BEGAPS (BEGin APplication Structure) and ends with ENDAPS (END APplication Structure). The first line identifies the application structure. Here we see a structure of type "grobject" with a unique identifier "callout1". The type grobject is defined in the WebCGM and ATA GREXCHANGE profiles. The second line defines an APSATTR (APplication Structure ATTRibute) called "name".

The following string contains information about the data associated with the attribute. 14 stands for a string, 1 for the number of strings to follow and finally 'Callout 123' as the string itself. By describing the syntax in this way it is possible to read the data even if the program does not know the meaning of the data itself.

The name attribute is used as a name for the graphical primitives contained in the application structure body. Finally, between the BEGAPSBODY (BEGin APplication Structure BODY) and the ENDAPS statements the graphical primitives appear, in this case a single restricted text element.