Du fait du support croissant de CGM version 4, le nombre des illustrations enregistrées et distribuées dans ce format a rapidement augmenté ces dernières années. Les profils dominants sont WebCGM et le profil ATA GREXCHANGE de l'Air Transport Association. La communauté CALS fait référence aux deux profils dans ses spécifications MIL-D-28003B.

Les différents profils prennent tous en charge l'enregistrement des métadonnées au sein d'un fichier CGM en utilisant la structure "grobject" qui est décrite à la fin de ce document. Il est toutefois interessant d'analyser plus en détail le stockage de ces métadonnées pour pouvoir tirer pleinement profit de tous les avantages de l'utilisation des fichiers CGM.

Que sont les métadonnées ?

D'une manière générale, toutes les informations non graphiques qui sont enregistrées dans un fichier graphique sont désignées métadonnées. Toutefois, dans ce contexte, je vous recommanderais de désigner ainsi  toutes les informations que vous souhaitez associer à une partie spéciale d'une illustration. Il pourrait s'agir d'un simple hotspot et d'une ID,  mais également d'une liste très sophistiquée d'informations sur un fil électrique dans un schéma de principe, par exemple le diamètre, les tensions, les valeurs de test, etc.

Nous devons distinguer ici différents cas de figures selon le profil que vous souhaitez utiliser :

WebCGM
WebCGM utilise la structure "grobject" pour enregistrer les informations non graphiques. Ce profil permet les attributs suivants :

ATA GREXCHANGE
Le profil ATA permet une phrase d'informations pratiquement identique :

id	l'ID unique de l'objet
name	un nom non unique pour cet objet
region	une zone de hotspot à cliquer
viewcontext	un rectangle cible pour le cas où l'objet est l'objectif d'un lien
screentip	une info-bulle qui est visible lorsque le curseur est placé sur l'objet
refLoc	un lien spécifique à l'ATA

Pas de profil spécifique
Si vous utilisez CGM version 4 sans profil spécifique, vous pouvez enregistrer toutes les informations que vous souhaitez dans le fichier CGM. Cela a toutefois pour conséquence que, typiquement, seuls les produits d'un unique fournisseur peuvent gérer les informations comme il est souhaité.

Ni WebCGM ni GREXCHANGE ne permettent d'enregistrer des informations supplémentaires dans un fichier CGM, et ce pour de bonnes raisons. Interopérabilité et fiabilité lors de l'échange de données entre les produits de différents fournisseurs sont les objectifs les plus importants de ces profils.

Si vous souhaitez enregistrer des informations supplémentaires avec vos objets graphiques, deux possibilités s'offrent à vous en général. Vous pouvez utiliser CGM 4 sans profil et enregistrer vos métadonnées en utilisant une DTD (Définition de Type de Document) propriétaire pour les objets graphiques. Cette méthode est prise en charge par IsoDraw et IsoView, mais pas forcément par d'autres produits.

La solution alternative recommandée est d'enregistrer les métadonnées en dehors du fichier CGM, en XML ou SGML dans un fichier associé. Cette approche garantit la compatibilité avec les produits CGM actuels et futurs.

Le fichier CGM ne doit contenir que des informations qui se rapportent directement au contenu graphique. Si l'on se réfère aux profils, il s'agit de :

• id: nécessaire pour identifier l'objet de façon unique
• name: nécessaire pour l'identification des objets par des noms courants, peut également être enregistré en dehors du fichier CGM
• region: il s'agit du contenu graphique, coordonnées et formes
• viewcontext: il s'agit d'un rectangle, également indiqué par ses coordonnées

Dans des cas simples, l'info-bulle et le lien URI peuvent également être enregistrés dans le fichier. Tous les autres attributs doivent être enregistrés en dehors.

Pourquoi et dans quel cas dois-je enregistrer les info-bulles et les liens en dehors du fichier CGM ?

Voyons deux cas de figure :

Cas 1:
Dans un fichier CGM, nous avons un grobject avec les attributs mentionnés précédemment. Nous ajoutons à l'objet une simple info-bulle désignant un numéro de pièce, par exemple "2376-A88". Nous avons un autre objet sur lequel nous voulons cliquer pour parvenir à une adresse web, donc nous ajoutons le lien URI http://www.itedo.com.

Il s'agit d'attributs statiques dans un cas simple et peuvent de ce fait facilement être enregistrés dans le fichier CGM.

Cas 2:
Supposons que nous ayons les mêmes objets dans le fichier CGM. Le problème qui se pose est que nous voulons utiliser le fichier dans différentes versions de langues de notre publication ou de notre IETM (Manuel Technique Electronique Interactif). Une simple info-bulle ne fonctionne alors pas. Il nous faut une méthode pour élaborer des info-bulles spécifiques aux différentes langues au moment de l'exécution.

Nous rencontrons le même problème lorsque notre lien dépend de l'utilisation du fichier, par exemple lorsque le fichier est utilisé dans un catalogue de pièces (lien vers un tableau des pièces) ou dans un manuel d'entretien (lien vers un texte de description).

Dans ce cas, il est judicieux de penser à un fichier associé comportant les informations nécessaires au moment de l'exécution.

Autres remarques

Jusqu'à présent, nous n'avons traité que des attributs autorisés de WebCGM et GREXCHANGE. Si nous voulons rester conformes et en même temps enregistrer des informations supplémentaires, il n'y a pas d'alternative à l'enregistrement externe.

Réflexions stratégiques

Si nous limitons les métadonnées dans le fichier CGM aux données qui sont vraiment nécessaires, nous profitons des avantages suivants :

• La structure grobject ainsi que les attributs cités sont restés stables pendant les 5 dernières années et ne seront pas modifiés pour une longue période encore. Ceci garantit la compatibilité avec les versions et produits CGM futurs.
• Toute métadonnée enregistrée en dehors du fichier CGM est bien plus simple à maintenir. Si un fichier XML/SGML associé est utilisé, tous les outils connus peuvent être utilisés pour manipuler les données selon le besoin.
• Dans un fichier associé, vous pouvez tout enregistrer. Il n'y a pas de dépendance vis-à-vis d'une implémentation CGM particulière d'un concepteur de logiciel.
• Le consortium AECMA (Association Européenne des Constructeurs de Matériel Aéronautique) a introduit le concept du fichier XML associé, par ailleurs repris dans d'autres secteurs de l'industrie.
  

Pour l'heure, il n'existe pas de Schema ou DTD spécifique pour un fichier associé au fichier CGM car les informations à enregistrer sont trop différentes et variées.

En principe, vous pouvez constituer ce genre de fichier XML de la manière suivante :

<cgmcompanion file="myCGMfile.cgm" .(autres attributs)>
  <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  ... etc. pour chaque objet
    ...
  />
</cgmcompanion>

A l'exécution, le visualiseur communiquera à l'environnement d'exécution l'événement relatif à la souris en utilisant l'ID du grobject. Une simple consultation suffit pour trouver le lien correct de cet objet et, si nécessaire, dépendant du contexte.

Dans la plupart des cas, il suffit d'enregistrer les métadonnées dans le fichier CGM - dans la mesure où nous travaillons avec des attributs autorisés. Il existe toutefois de nombreux cas pour lesquels il est recommandé d'enregistrer les liens et les attributs dans des fichiers séparés :

• Lorsque les attributs sont fréquemment modifiés ;
• Lorsque il est nécessaire d'accéder aux attributs à partir d'autres programmes, par exemple pour établir un lien entre textes et graphiques ;
• Si les fichiers doivent être gérés pendant une longue période avec de fréquences révisions;
• Lorsque l'interopérabilité est importante, par exemple si vous ne voulez pas être dépendant de l'implémentation CGM d'un fournisseur particulier ;
• Lorsque les attributs à enregistrer avec les objets graphiques ne sont autorisés dans aucun des profils CGM, par exemple un diamètre de fil electrique, un prix, une valeur de test, etc.
• Si vous avez actuellement des cas simples, mais que vous pressentez que vos exigences seront plus sophistiquées à l'avenir.

Les Application Structures (structures applicatives) sont nécessaires pour définir les hotspots dans les fichiers CGM. Le deuxième amendement de 1995 à la norme ISO/IEC 8632:1992 a ajouté les structures applicatives à CGM et a définit la version 4 comme étant la dernière version de CGM. Les Application Structures permettent l'insertion d'informations non graphiques dans le fichier associé avec divers éléments graphiques. L'amendement précise toutefois uniquement la syntaxe d'une Application Structure sans lui attribuer de sémantique. Voici l'exemple d'une structure applicative comportant un élément Restricted Text représenté selon un encodage Clear Text :

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

L'Application Structure commence par BEGAPS (BEGin APplication Structure) et finit par ENDAPS (END APplication Structure). La première ligne désigne l'Application Structure. Nous voyons ici une structure de type "grobject" avec un identifiant unique « callout1". Le type grobject est défini dans les profils WebCGM et ATA GREXCHANGE. La deuxième ligne définit un attribut d'une Application Structure APSATTR (APplication Structure ATTRibute) appelé "name".

La chaîne suivante comporte des informations sur les données associées à l'attribut. 14 représente une chaîne, 1 désigne le nombre de chaînes à suivre, et finalement 'Callout 123' correspond à la chaîne elle-même. En décrivant la syntaxe de cette manière, il est possible de lire les données même si le programme ne connaît pas la signification des données. L'attribut de nom est utilisé comme nom pour les primitives graphiques contenues dans le corps de l'Application Structure.

Enfin, apparaissent entre les déclarations BEGAPSBODY (BEGin APplication Structure BODY) et ENDAPS les primitives graphiques qui sont dans ce cas un unique élément Restricted Text.