Mit der gestiegenen Unterstützung für CGM der Version 4 ist auch die Anzahl der Illustrationen, die in diesem Format gespeichert und distribuiert werden, in den vergangenen Jahren schnell angestiegen. Die vorherrschenden Profile sind WebCGM und das ATA GREXCHANGE Profil der Air Transport Association. Die CALS-Gemeinde referenziert beide Profile aus ihrer MIL-D-28003B Spezifikation heraus.

Die verschiedenen Profile unterstützen alle das Speichern von Metadaten innerhalb einer CGM-Datei unter Verwendung der "grobject" Struktur, die am Ende dieses Dokuments beschrieben wird. Dennoch ist es lohnenswert, diese Metadaten etwas näher zu untersuchen, um die gesamten Vorteile der Verwendung von CGM-Dateien nutzen zu können.

Was sind Metadaten?

Im Wesentlichen werden alle nicht-grafischen Informationen, die in einer Grafik-Datei gespeichert sind, als Metadaten bezeichnet. In diesem Fall würde ich jedoch empfehlen, damit alle Informationen zu bezeichnen, die Sie mit einem speziellen Teil einer Illustration in Verbindung bringen möchten. Das könnte ein einfacher Hotspot oder eine ID sein, aber auch eine ausgereifte Liste an Informationen über einen Draht in einem Schaltbild, z.B. Durchmesser, Spannungen, Testwerte etc..

Hier müssen wir zwischen verschiedenen Fällen unterscheiden, je nachdem welches Profil Sie verwenden möchten:

WebCGM
WebCGM verwendet die "grobject" Struktur zum Speichern nicht-grafischer Information. Dieses Profil erlaubt die folgenden Attribute:

ATA GREXCHANGE
Das ATA Profil erlaubt einen fast identischen Satz an Informationen:

id	die eindeutige ID des Objekts
name	ein nicht-eindeutiger Name für das Objekt
region	eine klickbare Hotspot-Region
viewcontext	ein Zielrechteck, falls das Objekt das Ziel eines Links ist
screentip	ein Screentip, der sichtbar wird, wenn der Mauszeiger über das Objekt fährt
refLoc	einen ATA-spezifischen Link

Kein spezifisches Profil
Wenn Sie CGM der Version 4 ohne ein spezifisches Profil verwenden, können Sie jede beliebige Information innerhalb der CGM-Datei speichern. Das bedeutet jedoch, dass typischerweise nur Produkte eines einzelnen Herstellers die Informationen wie gewünscht verarbeiten können.

Wie speichere ich zusätzliche Informationen?

Weder WebCGM noch GREXCHANGE erlauben das Speichern zusätzlicher Informationen innerhalb einer CGM-Datei, und das hat gute Gründe. Interoperabilität und die Zuverlässigkeit beim Datenaustausch zwischen Produkten unterschiedlicher Hersteller sind das wichtigste Ziel dieser Profile.

Wenn Sie zusätzliche Informationen mit Ihren grafischen Objekten speichern möchten, gibt es dafür grundsätzlich zwei Möglichkeiten. Sie können CGM 4 ohne Profil verwenden und Ihre Metadaten unter Verwendung einer geschützten DTD für grafische Objekte speichern. Dieser Ansatz wird von IsoDraw und IsoView unterstützt, aber nicht notwendigerweise auch von anderen Produkten.

Die empfehlenswerte Alternative ist, die Metadaten in einer XML- oder SGML-Schwesterdatei außerhalb der CGM-Datei zu speichern. Dieser Ansatz stellt die Kompatibilität mit aktuellen und zukünftigen CGM-Produkten sicher.

Die CGM-Datei sollte nur Informationen beinhalten, die sich direkt auf den grafischen Inhalt beziehen. In Bezug auf die Profile sind dies
 

• id: wird zur eindeutigen Indentifizierung des Objekts benötigt
• name: wird zur Indentifizierung von Objekten durch gängige Namen benötigt, kann
  auch ausserhalb der CGM-Datei gespeichert werden
• region: dies sind grafische Inhalte, Koordinaten und Formen
• viewcontext: dies ist ein Rechteck, das ebenfalls in Koordinaten angegeben wird
  

In einfachen Fällen können auch der Screentip und die linkURI innerhalb gespeichert werden, alle anderen Attribute müssen außerhalb gespeichert werden.

Wann und warum sollte ich Screentips und Links ausserhalb der CGM-Datei speichern?

Betrachten wir zwei Fälle:

Fall 1
Innerhalb einer CGM-Datei haben wir ein grobject mit den vorhergenannten Attributen. Wir fügen einen einfachen, die Ersatzteilnummer bezeichnenden Screentip zu dem Objekt hinzu, z.B. "2376-A88". Wir haben ein anderes Objekt, das wir anklicken möchten, um zu einer Web-Adresse zu gelangen, also fügen wir die linkURI http://www.itedo.com hinzu.

Dieses sind statische Attribute in einem einfachen Fall, daher können sie leicht innerhalb der CGM-Datei gespeichert werden.


Fall 2
Wir haben die gleichen Objekte innerhalb der CGM-Datei. Das Problem liegt darin, dass wir die Datei in verschiedenen Sprachversionen unserer Publikation oder unserer technischen Dokumentation benutzen möchten. Somit funktioniert ein einfacher Screentip nicht, sondern wir benötigen eine Methode, um Sprachen-spezifische Screentips zur Laufzeit bereitzustellen. 

Das gleiche Problem tritt auf, wenn unser Link von der Verwendung der Datei abhängt, z.B. wenn die Datei in einem Teilekatalog verwendet wird (Link zu einer Stückliste) oder in einem Wartungshandbuch (Link zum beschreibenden Text).

In diesem Fall macht es Sinn, über eine Schwesterdatei nachzudenken, die die zur Laufzeit benötigte Information beinhaltet.

Zusätzliche Anmerkungen

Bisher haben wir nur die erlaubten Attribute von WebCGM und GREXCHANGE behandelt. Wenn wir konform bleiben und gleichzeitig Zusatzinformationen speichern möchten, führt kein Weg an der externen Speicherung vorbei.

Strategische Überlegungen

Wenn wir die Metadaten innerhalb der CGM-Datei auf die beschränken, die wirklich notwendig sind, kommen wir in den Genuß der folgenden Vorteile:

• Die grobject Struktur sowie die genannten Attribute sind während der vergangenen 5 Jahre nicht verändert worden und werden noch für eine lange Zeit stabil bleiben. Dies gewährleistet eine Kompatibilität mit zukünftigen CGM-Versionen und Produkten.
• Jegliche Metadaten, die außerhalb der CGM-Datei gespeichert sind, können leichter gewartet werden. Wenn Sie eine XML/SGML-Schwesterdatei verwenden, können Sie alle bekannten Werkzeuge nutzen, um die Daten nach Bedarf zu manipulieren.
• In einer Schwesterdatei kann alles gespeichert werden. Es gibt keine Abhängigkeiten von besonderen CGM-Anwendungen der Softwarehäuser.
• Die AECMA (European Aeronautics Consortium) hat das Konzept der XML-Schwesterdatei eingeführt, welches in anderen Industriezweigen übernommen wurde.
  

Derzeit gibt es kein spezifisches Schema oder eine DTD für eine CGM-Schwesterdatei, denn die zu speichernden Informationen unterscheiden sich zu stark.

Im Prinzip können Sie solch eine XML-Datei wie folgt aufbauen:
<cgmcompanion file="myCGMfile.cgm" .(andere Attribute)>
  <grobject
    id='myID1'
    screentipEng = 'my English screentip'
    screentipGer = 'mein deutscher Screentip'
    wireDia = '2.5 dia'
    link1 = '... ein Link'
    link2 = '... ein anderer Link'
    link3 = '... ein dritter Link'
  />
  <grobject  ... and so on for each object
    ...
  />
</cgmcompanion>

Zur Laufzeit berichtet der Viewer das Maus-Ereignis an die Laufzeitumgebung unter Verwendung der ID des grobjects. Ein einfaches Nachsehen reicht aus, um den richtigen Link für dieses Objekt zu finden, falls notwendig sogar kontextabhängig.

In den meisten Fällen wird es ausreichen, die Metadaten innerhalb der CGM-Datei zu speichern - sofern wir mit erlaubten Attributen arbeiten. Es gibt jedoch eine ganze Menge Fälle, in denen es empfehlenswert ist, die Links und Atttribute in separaten Dateien abzuspeichern:

• wenn die Attribute häufig geändert werden
• wenn von anderen Programmen aus auf die Attribute zugegriffen werden muss, z.B. zu Linktext und Grafiken
• wenn die Dateien über einen langen Zeitraum und mit häufigen Revisionen gewartet werden müssen
• wenn Interoperabilität wichtig ist, z.B. wenn Sie sich nicht von der CGM-Anwendung eines bestimmten Anbieters abhängig machen möchten
• wenn Attribute mit grafischen Objekten gespeichert werden müssen, die in keinem der CGM Profile erlaubt sind, z.B. ein Drahtdurchmesser, ein Preis, ein Testwert o.ä.
• wenn Sie zwar zur Zeit einfache Fälle haben, aber schon ahnen, dass Ihre Anforderungen in der Zukunft raffinierter werden

"Application structures" werden benötigt, um Hotspots in CGM-Dateien zu definieren. Der 2. Zusatz zur ISO/IEC 8632:1992 von 1995 fügte die Application Structures zu CGM hinzu und definierte die Version 4 als die aktuelle Version von CGM.

Application Structures erlauben die Einbindung nicht-grafischer Informationen in einer Datei, die mit verschiedenen grafischen Elementen verknüpft sind. Der Zusatz spezifiziert jedoch nur die Syntax einer Application Structure ohne ihr jegliche Semantik zuzuordnen. Hier ist ein Beispiel einer Application Structure, die ein begrenztes Textelement beinhaltet, welches in einer Klartext-Codierung dargestellt wird:

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

Die Application Structure beginnt mit BEGAPS (BEGin APplication Structure) und endet mit ENDAPS (END APplication Structure). Die erste Zeile bestimmt die Application Structure. Hier sehen wir eine Struktur des Typs "grobject" mit der eindeutigen Kennung "callout1".

Der Typ grobject ist in den WebCGM und ATA GREXCHANGE Profilen definiert. Die zweite Zeile definiert einen APSATTR (APplication Structure ATTRibute) namens "name". Der nachfolgende String beinhaltet Information über die dem Attribut zugeordneten Daten. 14 steht für einen String, 1 für die Anzahl an folgenden Strings und schließlich 'Callout 123' als der String selbst.

Dadurch, dass die Syntax auf diese Art beschrieben wird, ist es möglich, die Daten zu lesen auch wenn das Programm die Bedeutung der Daten selbst nicht kennt. Das Namens-Attribut wird als Name für die grafischen Primitive verwendet, die sich im Body der Application Structure befinden. Schließlich erscheinen zwischen den BEGAPSBODY (BEGin APplication Structure BODY) and ENDAPS Angaben die grafischen Primitive, in diesem Fall ein einzelnes begrenztes Textelement.