Page de couverture | Retour aux concepts de WebCGM | Vers le fichier d'accompagnement XML

WebCGM 2.0 : Le contenu intelligent de WebCGM

3 Le contenu intelligent de WebCGM

Cette section et ses sous-sections sont normatives, sauf indication contraire.

3.1 L'adressage des objets

3.1.1 La spécification des fragments IRI

3.1.1.1 La définition des fragments

Une adresse IRI (Internationalized Resource Identifier) est la façon dont une ressource est identifiée sur le Web. Par exemple, un fichier CGM nommé « web.cgm » pourrait avoir l'adresse IRI suivante :

http://example.org/web.cgm

Les structures d'application et les images au sein d'un fichier WebCGM sont appelées à l'aide du mécanisme de l'identificateur de fragment IRI. Ces règles WebCGM dérivent et sont compatibles avec les protocoles définis pour les adresses IRI [RFC 3987] et URI (Uniform Resource Identifier) [RFC 3986].

Une adresse IRI qui contient un identificateur de fragment IRI se compose d'une adresse IRI de base optionnelle, suivie d'un caractère séparateur « # », suivi de l'identificateur de fragment IRI. Par exemple, l'adresse IRI peut être utilisée pour indiquer l'objet « wheelAssembly » au sein du fichier « web.cgm » :

http://example.org/web.cgm#wheelAssembly

L'identificateur de fragment est habituellement seulement spécifique à une classe particulière d'applications. Cette clause définit l'identificateur de fragment WebCGM qui permet aux visualisateurs WebCGM, aux navigateurs Web, aux moteurs de scripts et à d'autres applications :

• D'addresser (de pointer vers) des objets spécifiques au sein des fichirs WebCGM,
• Ou de charger et appliquer un fichier d'accompagnement XML (XCF).

La syntaxe de fragment IRI, telle qu'adoptée par WebCGM, est fondée sur les concepts décrits dans « Le langage de pointeurs XML » (cf. la spécification « Le cadre XPointer »). La syntaxe de fragment IRI est définie ci-dessous. On donne la grammaire formelle du fragment WebCGM à l'aide d'une simple notation EBNF (Extended Backus-Naur Form).

Remarque n°1 : La précédente version WebCGM 1.0 autorisait plusieurs images par instance WebCGM. WebCGM 2.0 ne permet qu'une seule image par métafichier. Pour des raisons de rétrocompatibilité avec les métafichiers en version 1.0 et les visualisateurs existants, la syntaxe des fragments reste inchangée en ce qui concerne le terme « picterm ».

Remarque n° 2 : WebCGM 1.0 décrivaient les liens en utilisant la terminologie des adresses URI, tandis que les mises en œuvre interprétaient différemment le langage WebCGM 1.0 et certaines utilisaient essentiellement des adresses IRI (Internationalized Resource Identifiers). Les identificateurs IRI sont plus généralisés et complètent les identificateurs de ressources uniformes (URI). Une adresse IRI est une séquence de caractères issus du Jeu universel de caractères (Universal Character Set) [Unicode40]. Une adresse URI se construit à partir d'un jeu de caractères beaucoup plus réduit. Toutes les adresses URI sont des adresses IRI conformes. La spécification IRI définit une correspondance des identificateurs IRI aux identificateurs URI, et cette correspondance est adaptée à WebCGM ci-dessous (3.1.1.4). Les adresses IRI peuvent être converties en adresses URI si le processeur WebCGM ne gère pas directement les adresses IRI. Dans cette spécification, on utilise la terminologie IRI exacte.

3.1.1.2 La description EBNF des fragments

On utilise la notation suivante :

    *  — 0 ou plus
    +  — 1 ou plus
    ?  — 0 ou 1
    () — regroupement
    |  — options séparées
    des guillemets doubles « " » entourent les littéraux


webcgmfragment ::= picterm "." objterm | 
            picterm |
            objterm  |
            picid "." objid |
            objid | 
            xcfterm

picterm ::= pictureid | pictsequence

pictureid ::= "pictid("   picid   (","  behavior)? ")"

picid ::= (char)+

behavior ::=  "_blank" | "_self" | "_parent" | "_replace" | "_top" | target

target ::= (char)+

pictsequence ::= "pictseqno(" picseqno ("," behavior)? ")"

picseqno ::= (digit)+

digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 

objterm ::= specialForm | normalForm

specialForm ::= "id(*,clearHighlight)"

normalForm ::= objectid | objectname

objectid ::= "id("   objid   ("," objbehavior)? ")"

objid ::= (char)+

objBehavior ::= navTerm | highlightTerm | navTerm "+" highlightTerm

navTerm ::= "full" | "zoom" | "move"

highlightTerm ::= "newHighlight" | "addHighlight"

objectname ::= "name("   objname  ("," objbehavior)? ")"

objname ::= (char)+

xcfterm ::= "xcf(" xcfurl ")"

xcfurl ::= (char)+

Cf. la définition de la production « char » dans la section suivante.

3.1.1.3 Le répertoire des caractères de fragments

Les productions « picid », « target », « objid », « objname » et « xcfurl » dans la grammaire de fragment précédente sont représentées par des paramètres dans le contenu WebCGM de type texte non graphique (type String Fixed, ou SF, de CGM). Leur répertoire de caractères devra être réduit comme suit :

1. Premièrement, conformément au jeu de caractères des données de type SF. Cf. la section 6.3, règle T.14.5 ;
2. Deuxièmement, le répertoire de caractères pour toutes ces productions est restreint encore comme défini dans la section 2.2 de XML 1.0, troisième édition ;
3. Troisièmement, le répertoire de chaque production est à nouveau restreint comme suit :
   • objid - correspond au paramètre id de l'élément APS BEGIN de WebCGM ; restrictions supplémentaires : comme dans la structure name définie dans la section 2.3 de XML 1.0, troisième édition ;
   • objname - correspond à l'attribut APS WebCGM de type name ; il ne devra pas contenir (au début, à la fin ou au milieu) de caractères blancs « #x09 », « #x0a » ou « #x0d », ni de caractère espace « #x20 » au début et à la fin ; la chaîne d'un seul caractère "*" est réservée, elle a une signification spéciale et ce n'est pas une valeur objname valide ; pas d'autres restrictions ;
   • picid - correspond au paramètre id des éléments WebCGM BEGIN PICTURE ; autres restrictions : comme objid pour les apparitions de valeur picid dans un fragment, sinon selon le type SF du paramètre id dans l'élément BEGIN PICTURE même (cf. les autres commentaires ci-dessous) ;
   • target - autres restrictions : comme objid, mais doit commencer par [a-zA-Z], de la même façon que le nom du cadre cible de la « spécification HTML 4.01 », sur lequel l'ensemble des comportements d'images WebCGM se fonde ;
   • xcfurl - doit être une adresse IRI valide, conformément aux règles de codage ci-dessous (3.1.1.4), et doit obéir aux règles définies pour le premier paramètre de l'attribut de structure d'application linkuri.

Notez que ces répertoires de caractères admettent un ou plusieurs caractères point « . », virgule « , », parenthèse gauche « ( » et parenthèse droite « ) ». Ces caractères sont importants dans la syntaxe de la spécification de fragment WebCGM. Si l'un de ces quatres caractères significatifs apparaît dans une chaîne id/name valide dans une instance de fragment, alors le fragment utilisera la forme longue non abrégée, c'est-à-dire l'une des six formes optionnelles de la production « webcgmfragment » de 3.1.1.2. En particulier, tous les composants de la forme longue seront inclus et aucune partie marquée optionnelle dans la notation EBNF ne peut être omise.

Remarque à propos de picid : Le répertoire de caractères d'une apparition picid dans le fragment (en tant que objid) est plus restrictif que celui du paramètre id de l'élément BEGIN PICTURE même (type de données SF de CGM, sans autre restriction). Toute application qui utilise le champ picid dans le fragment doit générer les identificateurs d'images dans le répertoire plus restrictif du fragment. (Cf. une autre explication des mots-clés de sélection d'image dans les fragments, section 3.1.2.1.)

3.1.1.4 Les caractères non-URI dans les adresses IRI

Le répertoire de caractères URI, comme défini dans le document RFC 3986, comprend les caractères alphabétiques et numériques du code ASCII, plus quelques signes de ponctuation. Les répertoires de caractères définis dans la section 3.1.1.3 et admis dans les adresses IRI sont beaucoup plus riches. La méthode pour jongler avec cette disparité est décrite dans cette section.

Une adresse IRI dans un contenu WebCGM doit être une référence URI, comme définie dans le document RFC 3986, ou doit aboutir à une référence URI après que la procédure d'échappement en trois étapes a été appliquée, comme décrite dans le document RFC 3987 (IRI), section 3.1 (« Correspondance des adresses IRI aux adresses URI »), deuxième étape. La procédure s'applique lorsque le processeur WebCGM (un visualisateur ou tout autre processus interprétant du WebCGM) passe la référence URI à un résolveur URI (URI resolver).

Cette prise en charge permet à du contenu à des degrés de « légalité URI » variés (dans le sens du document RFC 3986) d'apparaître dans un contenu WebCGM, comme illustré dans les exemples à la fin de cette section. Dans le contexte WebCGM, les processeurs WebCGM peuvent déterminer pratiquement quand appliquer la procédure d'échappement en trois étapes : si une adresse IRI dans un contenu WebCGM contient une séquence de caractères correspondant à une séquence d'échappement URI valide, c'est-à-dire une séquence de trois caractères « %HH », le processeur WebCGM devra supposer qu'il s'agit d'une séquence d'échappement URI. Cette séquence peut être passée directement au résolveur URI. (C'est illustré dans les exemples).

Cela ne garantit toujours pas d'obtenir une adresse URI valide selon toutes les spécifications URI applicables. Par exemple, on pourrait avoir des caractères illégaux pour le système DNS dans le nom de domaine, si le contenu WebCGM en entrée, son générateur, était mal formé. Parce qu'il est difficile à une application de vérifier qu'une valeur correspond à une adresse URI valide, cette spécification suit en cela le document RFC 3986 et n'impose aucune obligation d'en tester la conformité aux applications WebCGM. Bien qu'aucune exigence de test de conformité ou de gestion d'erreur ne soit définie ici, les processeurs WebCGM devraient bien sûr réagir gracieusement à une entrée erronée.

3.1.1.5 La résolution des adresses IRI relatives des fichiers XCF

Le fragment EBNF précédent définit une production xcfterm dont le paramètre xcfurl désigne un fichier d'accompagnement XML associé au fichier WebCGM identifié par l'adresse IRI. Les visualisateurs WebCGM gérant XCF doivent interpréter le fragment puis localiser et charger le fichier XCF. Le paramètre xcfurl est lui-même une adresse IRI, qui peut être absolue ou relative. Le visualisateur WebCGM devra résoudre l'adresse IRI relative de xcfurl par rapport à l'adresse IRI de l'instance WebCGM que le fichier d'accompagnement XML accompagne, c'est-à-dire relativement au fichier WebCGM référencé par la partie de base de l'adresse IRI contenant le fragment, plutôt que par rapport au fichier contenant la référence IRI (par exemple, un fichier HTML).

3.1.2 Les paramètres de fragments

La sous-section suivante décrit en détail comment utiliser les paramètres de fragments pour indiquer les comportements d'images et les comportements d'objet des liens contenant les paramètres. On donne un résumé informatif des règles à la fin de cette section (3.1.2.7).

3.1.2.1 Les mots-clés de sélection d'image

Dans un environnement purement WebCGM 2.0, les mots-clés de sélection d'image sont d'utilisation limitée, car WebCGM 2.0 ne permet qu'une seule image par métafichier. Au contraire, WebCGM 1.0 en admettait plusieurs par métafichier. Les visualisateurs WebCGM 2.0 peuvent donc se mouvoir dans des environnements de l'héritage 1.0 ou « mixtes » 1.0/2.0 :

• Les visualisateurs WebCGM 2.0, spécialement lorsqu'ils mettent à jour ou remplacent des visualisateurs WebCGM 1.0, peuvent recevoir des requêtes externes liant à des métafichiers WebCGM 1.0 multi-images ;
• Des métafichiers WebCGM 2.0 ont peut-être besoin d'être liés à des métafichiers WebCGM anciens multi-images ;
• Des visualisateurs WebCGM 2.0 peuvent recevoir des requêtes pour des images non existantes dans des métafichiers d'une version quelconque, et il devrait y avoir un comportement de repli comme c'était le cas dans WebCGM 1.0.

pictid - Le mot-clé pictid indique que l'image à visualiser est identifiée par l'identificateur de l'image, c'est-à-dire le paramètre id dans l'élément BEGIN PICTURE. Dans la syntaxe, c'est un paramètre obligatoire de la production picterm, et il peut y avoir un deuxième paramètre associé dont la valeur est une définition optionnelle de comportement d'image (cf. le EBNF). Si le métafichier ne contient pas d'image avec la valeur d'identificateur d'image indiquée, la première image du métafichier (et seulement elle) est choisie.

pictseqno - Le mot-clé pictseqno indique que l'identité de l'image à visualiser est celle du numéro de séquence de l'image dans le métafichier (cf. le EBNF). Dans la syntaxe, c'est un paramètre obligatoire de la production picterm, et il peut y avoir un deuxième paramètre associé dont la valeur est une définition optionnelle de comportement d'image. Le numéro de séquence d'image devra être un entier supérieur à 0. Si la valeur de séquence d'image indiquée excède le nombre d'images dans le métafichier, la dernière image est affichée.

3.1.2.2 Les comportements d'images

Les comportements d'images décrivent au visualisateur comment afficher la ressource distante d'un hyperlien. Les comportements d'images sont fondés sur la syntaxe et la sémantique des noms des cadres cibles définis dans la « spécification HTML 4.01 ». Le concept des « comportements d'images » de WebCGM désignent collectivement les images CGM et les autres ressources Web. Les « comportements d'images » servent à indiquer le nom d'un contexte de présentation pertinent (par exemple, un cadre HTML ou XHTML, un élément iframe ou un élément object), dans lequel ouvrir un document lorsque le lien est activé.

Les noms réservés listés ci-dessous décrivent les divers comportements d'images. Toutes les autres valeurs de comportement d'image devront suivre les conventions d'écriture du contexte de présentation en question. Par exemple, si le contexte de présentation est un cadre HTML, alors c'est la convention d'écriture des noms des cadres cibles dans la « spécification HTML 4.01 » qui est adoptée ; si ce n'est pas un mot-clé réservé, il doit commencer par [a-zA-Z].

Pour la suite, les conventions suivantes s'appliquent :

• Le terme « visualisateur » désigne collectivement un navigateur et/ou un visualisateur CGM (par exemple, un module d'extension). Le résultat logique est décrit, pas la méthode pour obtenir le résultat (qui nécessitera en général une action du navigateur ou du visualisateur, ou des deux) ;
• Le terme « contenu » désigne soit la source, soit la destination d'un lien, et il s'agit soit d'une image (CGM), soit d'une autre ressource Web, selon la formulation du lien particulier.

Les valeurs de comportement d'image suivantes, sauf _replace, sont fondées sur les noms des cibles de cadres de HTML 4.01 :

"_blank"

Le visualisateur devra charger le contenu désigné dans une nouvelle fenêtre anonyme.

"_self"

Le visualisateur devra charger le contenu dans le même cadre que celui du contenu qui appelle cette cible.

"_parent"

Le visualisateur devra charger le contenu dans l'élément parent FRAMESET immédiat du cadre courant dans lequel le contenu est affiché. Cette valeur équivant à "_self" si le cadre courant n'a pas de parent.

"_replace"

Lorsque la valeur "_replace" apparaît dans un lien CGM-à-CGM, le visualisateur WebCGM devra remplacer l'image CGM courante par l'image CGM désignée, dans la même aire rectangulaire du même cadre que l'image qui appelle cette cible. Si la ressource finale (CGM) est la même que la ressource appelante, le visualisateur ne devra pas recharger la ressource. C'est le comportement par défaut de ces liens.

"_top"

Le visualisateur devra charger le contenu dans la totalité de la fenêtre originale (annulant ainsi tous les autres cadres). Cette valeur équivaut à "_self" si le cadre courant n'a pas de parent.

Si la valeur de comportement d'image est le nom d'un contexte de présentation pertinent (par exemple, un cadre HTML ou XHTML, un élément iframe ou un élément object), la ressource distante devra être affichée dans le contexte de présentation indiqué. Si le contexte de présentation existe déjà, il est réutilisé, en remplaçant le contenu existant. S'il n'existe pas, le visualisateur devra charger le contenu désigné (image ou document) dans une nouvelle fenêtre avec le nom indiqué. Remarquez que le cadre cible doit être un nom XML [XML10].

Les objets WebCGM sont souvent incorporés dans un langage parent. Dans une telle situation, les comportements d'activation de lien (les comportements d'images) sont définis par le langage concerné de l'objet parent . Par exemple, si le langage parent est HTML, alors le comportement d'activation de lien est défini par la « spécification HTML 4.01 » [HTML401].

<a href="someCGM.cgm" target="_blank" ... />

<a href="someCGM.cgm#picseqno(1,_blank)" ... /> 

Les figures n° 3 et 4 suivantes donnent des exemples pour "_self" et "_replace".

Figure n° 3. Exemple pour _self

Figure n° 4. Example pour _replace

3.1.2.3 Les mots-clés de sélection d'objet

id - l'identificateur de la structure d'application de type grobject, para ou subpara à sélectionner. Le paramètre id dans l'élément APS BEGIN. Sans correspondance dans l'image, aucun objet n'est sélectionné.

name - la valeur de l'attribut name dans un objet (structures d'application grobject, para ou subpara). C'est une autre méthode d'adressage des objets. Tous les objets dans l'image avec des attributs name correspondants sont sélectionnés. Sans correspondance dans l'image, aucun objet n'est sélectionné.

En plus de ces deux mots-clés de sélection d'objet, WebCGM définit un comportement d'objet de forme spéciale qui admet un mot-clé de sélection d'objet joker : "*". Le mot-clé joker s'emploiera uniquement dans cette forme spéciale.

3.1.2.4 Les comportements d'objets

Les comportements d'objets décrivent comment présenter la vue de l'objet (ou des objets) cible(s) d'un hyperlien contenant un fragment IRI sélectionnant un objet ou un groupe d'objets particuliers comme cible.

3.1.2.4.1 L'énumération des comportements

WebCGM 2.0 comprend 12 comportements d'objets distincts, dont onze sont générés par la définition EBNF des fragments et un est défini dans le EBNF comme un fragment de comportement d'objet de forme spéciale :

id(*,clearHighlight)

Le comportement d'objet par défaut est zoom+newHighlight.

La sous-section suivante définit le rectangle cible des comportements de navigation, selon qu'un seul ou plusieurs objets sont sélectionnés par le mot-clé de sélection d'objet. Les comportements de mise en évidence (highlight) s'appliquent à tous les objets sélectionnés selon le mot-clé de sélection d'objet.

Les comportements d'objets sont construits à partir d'un ensemble de trois mots-clés de navigation « atomiques » et d'un ensemble de deux mots-clés de mise en évidence « atomiques », définis ci-après. Les mots-clés de navigation n'ont aucun effet secondaire de mise en évidence et les mots-clés de mise en évidence n'ont aucun effet secondaire de navigation : les ensembles de mots-clés de navigation et de mise en évidence sont orthogonaux.

Le comportement de forme spéciale id(*,clearHighlight) ôte la mise en évidence de tous les objets en évidence dans l'image, sans affecter l'état de navigation de l'image.

Notez que les comportements d'objets sont cumulatifs. Comme décrit dans la section « Les comportements d'images », si un lien pointe vers le même fichier CGM en cours de visualisation, par exemple, un lien CGM-à-CGM dans un même fichier, avec un comportement d'image « _replace », alors l'image n'est pas rechargée, et tous les nouveaux comportements d'objets sont appliqués en commençant à l'état de visualisation courant de l'image.

Le tableau suivant énumère les comportements d'objets disponibles dans WebCGM 2.0. La colonne « Navigation » indique si le visualisateur effectue une navigation pour le comportement, pour les objets sélectionnés. La colonne « Mise en évidence » indique si le visualisateur ajuste la mise en évidence des objets sélectionnés de quelque façon (« X ») ou non.

WebCGM 1.0 définissait trois comportements d'objets que WebCGM 2.0 abandonne, à savoir view_context, highlight et highlight_all. Les visualisateurs WebCGM 2.0 devront prendre en charge ces trois comportements d'objets et devront le faire en les faisant correspondre aux comportements WebCGM 2.0 comme suit :

• view_context correspond à zoom+newHighlight
• highlight correspond à full+newHighlight
• highlight_all correspond à full+newHighlight

3.1.2.4.2 La définition du rectangle cible

Si une navigation vers un objet ou un groupe d'objets est définie, on doit calculer le rectangle cible comme suit :

• Si la structure d'application de l'objet contient un attribut APS viewcontext, le rectangle cible est décrit par lui ;
• Si la structure d'application de l'objet ne contient pas d'attribut viewcontext mais un attribut region, le rectangle cible est le rectangle englobant la région définie par cet attribut APS region ;
• Si la structure d'application de l'objet ne contient pas d'attribut viewcontext ni region, le rectangle cible est le rectangle englobant des primitives graphiques de l'objet ;
• Pour des objets sélectionnés multiples, le rectangle cible est le rectangle englobant des rectangles cibles des objets individuels, lesquels sont calculés d'après les trois définitions précédentes.

3.1.2.4.3 La définition des comportements

full

Le visualisateur devra présenter une vue d'image entière de l'image appropriée.

zoom

Le visualisateur devra ajuster le rectangle cible de l'objet (ou des objets) sélectionné dans le rectangle du visualisateur et le centrer.

move

Le visualisateur devra bouger (horizontalement) l'illustration de telle sorte que le rectangle cible soit centré dans le rectangle du visualisateur. S'il s'avérait que le périmètre d'extension VDC (VDC EXTENT) était déplacé à l'intérieur du rectangle du visualisateur, il dépend du visualisateur qu'il effectue ou non un centrage. Si le rectangle cible est trop grand, le visualisateur devra ajuster le rectangle cible dans le rectangle du visualisateur et le centrer.

newHighlight

Met en évidence l'objet (ou les objets) sélectionné, en ôtant d'abord toute mise en évidence existante des objets dans l'image.

clearHighlight

Met en évidence l'objet (ou les objets) sélectionné, en laissant en évidence les objets dans l'image qui le seraient déjà.

clearHighlight

Cf. la définition du fragment du comportement d'objet de forme spéciale dans l'énumération des comportements.

3.1.2.5 L'agrandissement et le panoramique

En plus de satisfaire aux exigences d'agrandissement et de panoramique établies par les définitions précédentes des comportements d'objets, et à celles d'agrandissement et de panoramique établies par la gestion des paramètres de l'élément object, les visualisateurs opérant dans un environnement interactif devront mettre à disposition des utilisateurs des commandes d'agrandissement et de panoramique. Les méthodes exactes et les styles d'interface utilisateur pour la sélection et la manipulation de l'agrandissement et du panoramique dépendent des visualisateurs.

3.1.2.6 Le fichier d'accompagnement XML

La syntaxe de fragment peut être utilisée pour charger et appliquer un fichier d'accompagnement XML (XCF) avec le fichier WebCGM. Un interpréteur gérant le modèle DOM de WebCGM devra d'abord charger le fichier WebCGM. Puis il chargera et appliquera le fichier d'accompagnement XML indiqué par la référence IRI (en résolvant une adresse IRI relative, le cas échéant). Finalement, il appliquera le fichier XCF avant le premier affichage de l'image CGM.

Les interpréteurs ne gérant pas le DOM de WebCGM peuvent ignorer ce type de fragment.

3.1.2.7 Le résumé des comportements

Le résumé suivant, informatif, est destiné à fournir des références vers les définitions normatives des comportements d'images et d'objets.

• Pour les liens contenant une adresse IRI avec un fragment IRI et ayant pour ressource distante un objet CGM, les comportements d'objets sont décrits dans la section 3.1.2.4 ;
• Pour l'activation de liens au sein d'un objet parent (par exemple, HTML), le comportement est défini par la spécification de langage pertinente de l'objet parent (par exemple, l'attribut HTML target de l'élément <a>), cf. la section 3.1.2.2. Tout comportement d'image dans un fragment IRI sera ignoré par les visualisateurs (cf. 3.1.2.2) ;
• Pour les liens dont l'origine est une ressource CGM, le comportement d'image s'exprimera à l'aide du troisième paramètre de l'attribut APS linkuri (cf. la section 3.2.2.3). Notez que le codage du comportement d'image dans le premier paramètre de l'attribut APS linkuri est déconseillé lorsqu'une ressource CGM est visée (cf. 3.2.2.3 « déconseillé ») ;
• Pour les liens de type script DOM vers CGM, l'attribut src de l'interface WebCGMMetafile définit l'adresse IRI de l'image. Il n'est pas permis de définir un comportement comme partie de l'adresse IRI (cf. 5.7.3 « l'attribut src »).

3.1.3 Exemples

Cette section et ses sous-sections sont informatives (non normatives).

3.1.3.1 Les préalables

Le fragment WebCGM dans sa forme la plus verbeuse fournit les méthodes pour adresser des objets entre les métafichiers et indique au visualisateur quoi faire pour exécuter le lien. Le comportement par défaut du visualisateur définit ce que le navigateur devra faire si le fragment WebCGM ne définit pas explicitement le comportement du visualisateur.

Les exemples suivants illustrent quelques utilisations du fragment WebCGM. Les exemples décrivent comment on pourrait adresser une ensemble de fichiers CGM en rapport avec les diverses vues d'un moteur, stockés sur le site example.org (http://example.org/webcgm/). Les fichiers CGM contiennent les diverses vues d'un assemblage de moteur, la vue de dessus (top), la vue de face (front), la vue de droite (right), la vue de gauche (left) et la vue isométrique (isometric). Les fichiers CGM sont identifiés comme suit :

Métafichier n° 1 : "engine_top.cgm"

Métafichier n° 2 : "engine_front.cgm"

Métafichier n° 3 : "engine_right.cgm"

Métafichier n° 4 : "engine_left.cgm"

Métafichier n° 5 : "engine_iso.cgm"

Chaque métafichier contient une seule image, dont l'identificateur est identique au nom du métafichier (sans le « .cgm »), avec plusieurs objets identifiables, à savoir la pompe à huile, la culasse, le ventilateur, le radiateur ou l'allumage. Les objets ne sont pas tous montrés dans toutes les vues.

Les objets contenus dans chaque métafichier sont les suivants :

Métafichier n° 1 :

Pompe à huile : id='oil-pump-t' name='lube-system'

Culasse : id='cyl-hd-t' name='engine'

Ventilateur : id='fan-t' name='cooling'

Radiateur : id='rad-t' name='cooling'

Distributeur : id='dist-t' name='ignition'

Métafichier n° 2 :

Pompe à huile : id='oil-pump-f' name='lube-system'

Culasse : id='cyl-hd-f' name='engine'

Ventilateur : id='fan-f' name='cooling'

Radiateur : id='rad-f' name='cooling'

Distributeur : id='dist-f' name='ignition'

Métafichier n° 3 :

Pompe à huile : id='oil-pump-r' name='lube-system'

Culasse : id='cyl-hd-r' name='engine'

Ventilateur : id='fan-r' name='cooling'

Radiateur : id='rad-r' name='cooling'

Métafichier n° 4 :

Culasse : id='cyl-hd-l' name='engine'

Ventilateur : id='fan-l' name='cooling'

Radiateur : id='rad-l' name='cooling'

Distributeur : id='dist-l' name='ignition'

Métafichier n° 5 :

Pompe à huile : id='oil-pump-i' name='lube'

Culasse : id='cyl-hd-i' name='engine'

Ventilateur : id='fan-i' name='cooling'

Radiateur : id='rad-i' name='cooling'

Distributeur : id='dist-i' name='ignition'

3.1.3.2 Exemple n° 1

1^er paramètre : http://example.org/webcgm/engine_top.cgm#pictseqno(1).id(cyl-hd-t,full+newHighlight)
3^ème paramètre : _blank

Lorsqu'utilisé comme valeur de l'attribut APS linkuri (les 1^er et 3^ème paramètres) d'un objet dans un fichier CGM, cet exemple récupère le fichier CGM engine_top.cgm auprès du site Web example.org et affiche la première (seule) image dans une nouvelle fenêtre, en mettant en évidence l'objet dont l'identificateur id vaut "cyl-hd-t" en vue d'image entière. La fenêtre d'affichage existante reste inchangée. Les expressions ci-dessus représentent la forme préférée (cf. la section 3.2.2.3) lorsque le lien est inclus dans un contenu CGM. La forme suivante est légale mais déconseillée (elle sera peut être supprimée dans les versions futures de WebCGM) :

http://example.org/webcgm/engine_top.cgm#pictseqno(1,_blank).id(cyl-hd-t,full+newHighlight)

3.1.3.3 Exemple n° 2

http://example.org/webcgm/engine_top.cgm#pictid(engine_top).id(oil-pump-t,full+newHighlight)

Lorsqu'utilisé comme adresse IRI d'un élément object en HTML, cet exemple affiche l'image CGM dans un rectangle défini par les paramètres width et height de la balise object, en affichant l'image entière avec la pompe en évidence.

3.1.3.4 Exemple n° 3

Adresse IRI : http://example.org/webcgm/engine_iso.cgm#id(dist-i,zoom+newHighlight)
Attribut HTML target : topframe

Lorsqu'utilisé comme valeur de l'adresse IRI pour cibler un objet dans fichier CGM depuis un fichier HTML, cette adresse IRI (plus l'attribut HTML) récupère le fichier CGM engine_iso.cgm sur le site Web example.org et affiche l'image du métafichier dans le cadre nommé "topframe", en mettant en évidence l'objet dont l'identificateur vaut "dist-i". Si présent, on utilise l'attribut APS viewcontext de l'objet "dist-i" pour déterminer la portion rectangulaire de l'image à afficher dans le cadre, sinon le calcul d'une solution de repli d'un rectangle cible.

3.1.3.5 Exemple n° 4

1^er paramètre : http://example.org/engine_front.cgm
3^ème paramètre : topframe

Lorsqu'utilisé comme valeur de l'attribut linkuri pour cibler un objet dans un fichier CGM depuis un autre fichier CGM, cet attribut linkuri (1^er et 3^ème paramètres) récupère le fichier CGM engine_front.cgm auprès du site Web example.org et affiche l'image du métafichier dans le cadre nommé "topframe", en vue d'image entière. (Cf. l'exemple n° 1, à propos d'autres formes déconseillées).

3.1.3.6 Exemple n° 5

http://example.org/webcgm/engine_top.cgm#name(cooling)

Cet exemple récupère le fichier CGM engine_top.cgm auprès du site Web example.org et affiche l'image du métafichier. La vue s'agrandit sur le rectangle cible, lequel contient tous les objets dont l'attribut APS name vaut "cooling", chacun étant mis en évidence.

3.1.3.7 Exemple n° 6

http://example.org/webcgm/engine_top.cgm#fan-t

Cet exemple récupère le fichier CGM engine_top.cgm auprès du site Web example.org et afficher la première (seule) image du métafichier. La vue s'agrandit au rectangle cible calculé de l'objet dont l'identificateur id vaut "fan-t", celui étant mis en évidence.

3.1.3.8 Exemple n° 7

#id(oil-pump-t, addHighlight)

Cet exemple laissera inchangés les facteurs courants d'agrandissement et de panoramique dans l'image affichée courante et mettra en évidence l'objet dont l'identificateur vaut "oil-pump-t". Les autres objets déjà mis en évidence dans l'image le restent.

3.2 Les descriptions des structures d'application et des attributs APS

3.2.1 Les structures d'application

WebCGM définit les types suivants de structures d'application (APS) : layer, grobject, para, subpara et grnode. Ce document emploie le terme « objet » pour désigner une structure d'application de type grobject, para ou subpara.

Quoique le corps d'image (N.d.T. picture body) d'une image WebCGM ne soit pas lui-même une structure d'application, les règles de contenu du corps d'image (picbody) sont définies par ce bout d'EBNF (cf. la syntaxe de fragment pour une définition de la notation) :

picbody ::= layer+ | 
            (grobject | para | grnode | gdata)*

C'est-à-dire qu'un corps d'image contient soit une ou plusieurs couches (layer), soit une collection de structures d'application éligibles (grobject, para, grnode) et des données graphiques (gdata). Les règles de contenu de ces structures d'application sont définies dans les sections suivantes.

CGM:1999 impose que l'élément APS BEGIN de chaque structure d'application ait un paramètre identificateur unique. Le répertoire de caractères du paramètre id d'une structure APS dans un contenu WebCGM est identique au répertoire défini pour la production du fragment objid dans la section 3.1.1.3.

3.2.1.1 grobject

Description : La structure d'application (APS) de type grobject sert à regrouper les primitives graphiques d'une image et à assigner certains attributs au groupe. L'objet est identifié géométriquement soit par l'ensemble de primitives englobé par les éléments BEGIN APS BODY et END APS (le cas échéant), soit par la région spatiale associée à l'attribut APS region (si présent). Les structures d'application de type grobject peuvent contenir n'importe quel contenu graphique CGM permis par ce profil.

Définition : La région interactive d'un objet est la région géométrique effective pour les besoins de toutes les opérations interactives de curseur et de souris, tels que la sélection et le survol par la souris. Par défaut, la région interactive est définie par les primitives graphiques dessinées de l'objet. Pour les primitives d'aires remplies, cela comprend : le bord (edge), si la visibilité de bord vaut "on" ; l'intérieur, si le style d'intérieur (interior style) ne vaut pas "empty" ni "hollow" ; et la frontière (boundary) si le style d'intérieur vaut "hollow". Pour tous les types de primitives graphiques, sont exclues des primitives graphiques dessinées celles qui sont totalement transparentes (un objet totalement transparent équivaut donc à un objet vide, en ce qui concerne la définition de la région interactive). Si l'objet contient un attribut APS region, alors l'aire de cette région est la région interactive.

Modèle de contenu : Le contenu d'une structure d'application de type grobject est le suivant (cf. la syntaxe de fragment pour une définition de la notation EBNF) :

• grobject ::= (grobject | para | grnode | gdata)*
• Une structure d'application grobject peut aussi contenir les attributs APS optionnels des types suivants : region, viewcontext, linkuri, screentip, name, visibility, interactivity.

Comportement du visualisateur : La sélection ("pick") d'une structure d'application grobject, ainsi que celle d'autres objets (APS) pouvant être la cible d'un événément "pick", obéit aux règles des événements DOM de WebCGM. Ces règles déterminent tous les aspects du traitement de l'événement, y compris la sélection du bon objet cible lorsqu'il y a plusieurs candidats éligibles, et de la sélection du bon descripteur pour traiter l'événement. Le visualisateur devra fournir à l'utilisateur une confirmation visuelle du succès de la sélection et une indication de l'objet particulier (ou de la région) qui a été sélectionné. La méthode exacte de confirmation dépend du visualisateur.

Si une structure d'application est la cible d'un lien, depuis l'intérieur de l'image ou bien depuis un contenu extérieur à l'image, alors le comportement du visualisateur sera celui défini dans la section « Les comportements d'objets ».

Le standard CGM:1999 permet de continuer la définition d'une structure d'application en tronçons disjoints dans le fichier. S'il se présente une structure d'application ayant la même valeur de paramètre id que celle d'une structure d'application précédente, alors cela est interprété comme une continuation de la définition de cet objet. Les instances de métafichiers WebCGM 2.0 ne devront pas contenir de structures APS continuées.

3.2.1.2 layer

Description : La structure d'application layer déclare que le contenu graphique dans cette structure et toute structure APS imbriquée valide (grobject, para et grnode, mais pas layer) appartiennent à la couche identifiée par l'attribut APS layername que celle-ci porte.

Modèle de contenu : Le contenu d'une structure d'application de type layer est le suivant (cf. la syntaxe de fragment pour une définition de la notation EBNF) :

• layer ::= (grobject | para | grnode | gdata)*
• Exactement, un seul attribut APS de type layername
• La structure d'application layer peut aussi contenir les attributs APS optionnels des types suivants : layerdesc, visibility, interactivity.

Comportement du visualisateur : Les visualisateurs devront fournir une fonctionnalité pour informer les utilisateurs de la présence de couches, avec leurs noms et descriptions. Les visualisateurs devront fournir un moyen d'activer ou de désactiver sélectivement la visibilité des couches. Ils peuvent, sans obligation, fournir en supplément une fonctionnalité de manipulation de vues et de lecture des couches.

3.2.1.3 para

Description : La structure d'application (APS) de type para peut être utilisée pour identifier du texte (des « paragraphes »). La structure para et l'attribut content ensemble sont potentiellement exploitables par les applications pour construire une fonctionnalité de recherche dans le texte, spécialement dans les cas où les données graphiques sous-jacentes ne comprennent pas de texte graphique dans une forme explorable (par exemple, le texte a été rastérisé, polygonisé, ou des chaînes qui visuellement n'en forment qu'une ont été fragmentées en plusieurs éléments de texte plus petits). Les structures d'application para peuvent contenir n'importe quel contenu graphique CGM permis par ce profil.

Modèle de contenu : Le contenu d'une structure d'application de type para est le suivant (cf. la syntaxe de fragment pour une définition de la notation EBNF) :

• para ::= (subpara | gdata)*
• La structure d'application para peut aussi contenir les attributs APS optionnels des types suivants : region, viewcontext, linkuri, screentip, name, content, visibility, interactivity.

Comportement du visualisateur : En ce qui concerne la sélection des objets et la navigation des liens, le traitement de para par le visualisateur est identique à celui de grobject (3.2.1.1).

Cette version de WebCGM n'établit pas de standard pour la recherche dans le texte, mais fournit des méthodes avec lesquelles les applications peuvent construire cette fonctionnalité. On prévoit qu'une version future définira une fonctionnalité de recherche standard.

3.2.1.4 subpara

Description : La structure d'application (APS) de type subpara peut servir à identifier des fragments de texte plus petits au sein d'une structure APS de type para. Cela permet, par exemple, l'identification du bloc de texte plus grand (le « paragraphe ») pour des besoins de recherche, et le marquage de fragments plus petits comme points sensibles. La structure d'application subpara peut contenir n'importe quel contenu graphique CGM permis par ce profil, mais pas de structure d'application imbriquée. Les règles de contenu des attributs APS de subpara correspondent à celles de para.

Modèle de contenu : Le contenu d'une structure d'application de type subpara est le suivant (cf. la syntaxe de fragment pour une définition de la notation EBNF) :

• subpara ::= (gdata)*
• La structure d'application subpara peut aussi contenir les attributs APS optionnels des types suivants : region, viewcontext, linkuri, screentip, name, content, visibility, interactivity.

Comportement du visualisateur : Cf. 3.2.1.3 para.

3.2.1.5 grnode

Description : La structure d'application (APS) de type grnode est uniquement destinée à regrouper des primitives graphiques de base. Pour cette raison, la structure grnode doit contenir le paramètre APS id exigé par CGM:1999 pour toutes les structures d'application, mais elle ne peut pas contenir d'éléments attributs APS. Toutefois, le contenu d'une structure grnode ne se limite pas aux primitives graphiques. Le contenu APS admissible d'une structure grnode est le même que celui de la structure d'application grobject.

Même si les attributs visibility et interactivity ne sont pas permis sur elle, la structure d'application grnode gère l'héritage (c'est-à-dire qu'il est possible de rendre une structure grnode visible ou invisible en l'insérant dans un objet qui accepte l'attribut visibility).

Modèle de contenu : Le contenu admissible d'une structure d'application de type grnode est le suivant :

• grnode ::= (grobject | para | grnode | gdata)*

Comportement du visualisateur : À la différence des autres structures d'application, la structure grnode n'est pas interactive, c'est-à-dire qu'elle ne reçoit pas d'événements de souris. Si un événement de souris est déclenché sur la géométrie d'une structure grnode, un nœud ancêtre de type grobject peut répondre à l'événement. De fait, le contenu d'une structure grnode pourrait apparaître interactif, par exemple, si la structure grnode était un sous-élément direct d'une structure grobject. Cf. « L'interface Event » pour plus de renseignements concernant les événements de souris.

3.2.1.6 À propos des éléments de métadonnées généraux

Description : Cette version et ce niveau de WebCGM interdit l'apparition d'éléments APS supplémentaires hormis grobject, layer, para, subpara et grnode. On peut associer des métadonnées privées aux objets WebCGM en stockant les métadonnées hors du fichier CGM, en les associant aux objets dans le fichier CGM. Un moyen de lier des métadonnées privées externes à des instances WebCGM est défini dans la section « Le fichier d'accompagnement XML » ( XCF).

3.2.2 Les attributs des structures d'application

3.2.2.1 region

Valeur initiale : aucune
S'applique à : grobject, para, subpara
Hérité : non

Description : L'attribut APS region procure une région spatiale optionnelle, associée à un objet graphique, qui s'approprie la priorité des traitements d'événements de souris dirigés sur l'objet, tels que la sélection, le survol de la souris, etc. Si présent, cet attribut APS définit la région interactive de l'objet, sinon elle est définie par la géométrie de l'objet.

On peut définir des régions simples de type rectangle, ellipse, polygone et polybézier. Des régions complexes réunissant des ensembles de régions simples peuvent être construites, en permettant la définition de sous-régions disjointes, de régions avec des trous, etc. Leur sémantique (sous-régions et définition de l'intérieur/extérieur) est identique à celle de l'élément CGM CLOSED FIGURE. Une structure APS ne peut avoir qu'un seul attribut region au plus.

Paramètres : L'enregistrement de données est une valeur structurée SDR (N.d.T. Structured Data Record) d'un ou plusieurs couples membres (c'est-à-dire 2*m membres, m>=1). Chaque couple membre définit une région simple : le premier membre est du type de données Index, dont les valeurs légales sont :

• 1 : rectangle
• 2 : ellipse
• 3 : polygone
• 4 : polybézier continu

Le second membre est de type VDC (Virtual Device Coordinate) :

• Pour un rectangle : 4 valeurs VDC définissant deux points d'angle ;
• Pour une ellipse : 6 valeurs VDC définissant respectivement le centre et les deux points limites CDP (Conjugate Diameter Pair endpoints) ;
• Pour un polygone : 2n valeurs VDC définissant les sommets du polygone ;
• Pour un polybézier : 2*(3n+1) valeurs VDC, représentant 3n+1 points, définissant n segments de Bézier cubiques contigus ;

Pour les régions des polygones et des polybéziers, la fermeture est implicite (si le dernier point ne correspond pas au premier, le visualisateur clôt alors la région par une ligne droite allant du premier point au dernier).

Au cas où il y a plusieurs régions simples m>1, alors les régions simples individuelles correspondent chacune à un élément REGION au sens de l'élément CGM CLOSED FIGURE.

Comportement du visualisateur : Cf. 3.2.1.1.

3.2.2.2 viewcontext

Valeur initiale : aucune
S'applique à : grobject, para, subpara
Hérité : non

Description : L'attribut APS viewcontext fournit au visualisateur une définition de la vue initiale d'un objet, lorsque le visualisateur a été conduit à naviguer vers l'objet graphique contenant cet attribut. Un attribut APS viewcontext peut être contenu dans une structure d'application sinon vide, auquel cas la structure d'application fournit seulement une définition de la zone de visualisation. Il ne peut y avoir qu'un seul attribut viewcontext au plus dans une structure d'application.

Paramètres : L'enregistrement de données est une valeur structurée SDR d'un seul membre de type VDC définissant les deux points d'angle d'un rectangle.

Comportement du visualisateur : Cf. 3.2.1.1.

3.2.2.3 linkuri

Valeur initiale : aucune
S'applique à : grobject, para, subpara
Hérité : non

Description : L'attribut APS linkuri définit une adresse IRI, à associer à l'objet contenant cet atribut. Si l'objet est sélectionné dans une opération de sélection graphique et que le modèle d'événements WebCGM détermine qu'un traitement d'hyperliaison devra prendre en charge l'événement, alors le visualisateur devra prendre les mesures nécessaires pour naviguer dans ce lien. Une seule structure d'application peut contenir plusieurs attributs linkuri. Si l'objet contient plusieurs attributs linkuri, l'utilisateur devra avoir le choix de l'adresse IRI où naviguer.

Paramètres : L'enregistrement de données est une valeur structurée SDR d'un seul membre, contenant trois chaînes (type SF, String Fixed). La première chaîne est la destination du lien (une adresse IRI), la deuxième chaîne (éventuellement nulle) est un paramètre LINK TITLE et la troisième (éventuellement nulle) est le paramètre BEHAVIOR. Notez qu'une chaîne nulle est une chaîne de longueur zéro, ce qui est différent d'un paramètre omis. Le paramètre ne doit pas être omis.

La destination d'un lien est indiqué par un identificateur de ressource internationalisé, ou adresse IRI. Cf. la section 3.1.1.4 pour une explication détaillée de ce paramètre. Cette spécification ne contraint pas la syntaxe ni la sémantique de l'adresse IRI d'un attribut linkuri identifiant une ressource qui n'est pas un fichier CGM (par exemple, un document HTML ou XML).

La chaîne de comportement définit le comportement d'image associé au lien. Les valeurs et significations sont celles définies dans la section 3.1.2.2. Au cas où la destination n'est pas un type de média CGM, le 3^ème paramètre BEHAVIOR devra être utilisé s'il faut définir un comportement d'image au lien (il n'y a pas d'autre option). La chaîne BEHAVIOR peut aussi être utilisée pour les liens vers les types de médias CGM, c'est la méthode préférée.

Au cas où l'adresse IRI pointe vers un type de média CGM, le comportement d'image peut être codé dans l'identificateur de fragment optionnel conjointement à la structure IRI, d'après la section 3.1.1, « La définition du fragment IRI ». Cette forme est déconseillée et pourra être supprimée dans une future édition de ce profil. Pour définir un comportement d'image, les instances linkuri WebCGM particulières devront utiliser soit la chaîne BEHAVIOR (préféré), soit la définition de comportement d'image incorporée dans le fragment (déconseillé), mais pas les deux.

3.2.2.4 layername

Valeur initiale : aucune
S'applique à : layer
Hérité : non

Description : L'attribut APS layername déclare que le graphique associé à la structure d'application layer contenant cet attribut appartient à la couche identifiée. L'attribut layername n'est pas nécessairement unique. Si plusieurs structures layer contiennent le même attribut layername, alors celles après la première seront interprétées comme continuant la définition de la couche nommée. Il doit y avoir exactement un seul attribut layername dans chaque structure d'application layer.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed), le nom de couche (identificateur). La chaîne peut être nulle (longueur zéro). Si le nom de couche est nul, alors le graphique de cet objet appartient à la couche nulle.

Comportement du visualisateur : Cf. 3.2.1.2.

3.2.2.5 layerdesc

Valeur initiale : aucune
S'applique à : layer
Hérité : non

Description : L'attribut APS layerdesc fournit un texte descriptif optionnel associé à la structure d'application layer dans laquelle il apparaît. Les visualisateurs peuvent l'utiliser afin de faciliter les fonctions de manipulation des couches obligatoires et optionnelles, comme décrit dans la section 3.2.1.2. Il ne peut y avoir qu'un seul attribut layerdesc au plus dans une structure d'application layer.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed).

Comportement du visualisateur : Cf. 3.2.1.2.

3.2.2.6 screentip

Valeur initiale : aucune
S'applique à : grobject, para, subpara
Hérité : non

Description : L'attribut APS screentip fournit une chaîne optionnelle, à associer à un objet graphique, que les visualisateurs peuvent afficher lorsque le pointeur graphique survole la région interactive de l'objet graphique. Que l'affichage de l'infobulle survienne réellement ou non dépend de la façon dont le modèle d'événements WebCGM détermine le traitement des survols de souris. Cet attribut APS peut apparaître dans n'importe quel objet graphique de WebCGM, spécialement dans les structures d'application de type grobject, para et subpara, et il ne devra y en avoir qu'un seul au plus dans chaque structure d'application particulière.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed).

Comportement du visualisateur : Les visualisateurs devront être capables d'afficher l'infobulle, s'il y en a une définie pour l'objet graphique, qui soit visible à l'utilisateur lorsque le pointeur survole l'objet graphique, dans le style courant des navigateurs Web.

3.2.2.7 name

Valeur initiale : aucune
S'applique à : grobject, para, subpara
Hérité : non

Description : L'attribut APS name fournit une chaîne optionnelle, qui définit un « nom commun » associé à un objet. À la différence du paramètre APS id, l'attribut name n'a pas besoin d'être unique dans un métafichier. Une structure d'application peut contenir plusieurs attributs name.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed). Le répertoire de caractères de l'attribut APS name dans un contenu WebCGM est identique à celui défini pour la production du fragment objname dans la section 3.1.1.3.

Comportement du visualisateur : L'attribut name apporte aux applications un moyen d'associer des noms communs aux objets. L'objet peut être adressé en option par la valeur de l'attribut name. Cf. 3.1.1.

3.2.2.8 content

Valeur initiale : aucune
S'applique à : para, subpara
Hérité : non

Description : L'attribut APS content fournit un moyen de déclarer ce qui est du contenu textuel dans les structures d'application para et subpara. Il est offert comme base sur laquelle les applications peuvent construire une recherche dans le texte (qui ne fait pas l'objet d'une normalisation supplémentaire dans cette version de WebCGM). Le texte apparent dans un affichage graphique ne correspondra peut-être pas à des chaînes de texte reconnaissables dans le contenu même du métafichier. Par exemple, le contenu du métafichier peut dessiner le texte avec des éléments matriciels, ou avec des traits remplis, ou un caractère à la fois dans un ordre aléatoire, etc.

L'attribut content d'une structure d'application para devrait contenir tout le texte rendu de la structure para, et l'attribut content d'une structure d'application subpara tout le texte rendu de la structure subpara. L'attribut APS content ne peut apparaître que dans les structures d'application de type para et subpara, et il devra n'y en avoir qu'un seul au plus dans ces structures.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed).

Comportement du visualisateur : Cf. la description sous la structure d'application para dans la section 3.2.1.3.

3.2.2.9 visibility

Valeur initiale : "on"
S'applique à : layer, grobject, para, subpara
Hérité : oui

Description : L'attribut visibility indique si un objet est visible ou non. L'attribut visibility s'applique aux structures d'application (APS) de type layer, grobject, para et subpara. La valeur de visibility est héritée par tous les objets descendants de type layer, grobject, para et subpara. Bien qu'on ne puisse pas le définir sur la structure grnode ni l'y appliquer, l'attribut visibility est aussi hérité par les objets de type grnode et tous leurs descendants dans la structure WebCGM en héritent.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed). Les valeurs légales sont "off", "on" et "inherit".

Comportement du visualisateur : Un objet non visible ne s'affiche pas. L'objet non visible se comporte comme un objet non interactif (c'est-à-dire qu'on ne peut pas le cliquer ni le mettre en évidence). Cela n'implique pas que la valeur de l'attribut interactivity change pour "off" mais simplement que l'agent utilisateur ne doit pas répondre aux événéments de souris.

3.2.2.10 interactivity

Valeur initiale : on
S'applique à : layer, grobject, para, subpara
Hérité : oui

Description : L'attribut interactivity indique si un objet peut recevoir des événements de souris. L'attribut interactivity s'applique aux structures d'application (APS) de type layer, grobject, para et subpara. La valeur de l'attribut interactivity est héritée par tous les objets descendants de type layer, grobject, para et subpara. Bien qu'on ne puisse pas le définir sur la structure grnode ni l'y appliquer, l'attribut interactivity est aussi hérité par les objets de de type grnode et tous leurs descendants dans la structure WebCGM en héritent.

Paramètres : L'enregistrement de données est une valeur structurée d'un seul membre, contenant une seule chaîne (type SF, String Fixed). Les valeurs légales sont "off", "on" et "inherit".

Comportement du visualisateur : Si l'attribut interactivity d'un objet à la valeur "off", les événements sont désactivés pour cet objet. Cela a pour effet de désactiver les descripteurs d'événements, les changements de pointeur, la mise en évidence, les infobulles et l'hyperliaison du nœud donné et ses descendants. Un objet qui est cible d'un lien répond toujours à une mise en évidence, indépendamment de la valeur de son attribut interactivity.

3.2.2.11 À propos des éléments de métadonnées généraux

Description : Cette version et ce niveau de WebCGM interdit l'apparition d'éléments APS supplémentaires hormis ceux énumérés précédemment. On peut associer des métadonnées privées aux objets WebCGM en stockant les métadonnées hors du fichier CGM, en les associant aux objets dans le fichier CGM. Un moyen de lier des métadonnées privées externes à des instances WebCGM est défini dans la section « Le fichier d'accompagnement XML » ( XCF).

3.3 Le modèle de contenu

Cette sous-section est informative (non normative).

Voici un résumé informatif de l'ensemble du modèle de contenu de la fonctionnalité CGM version 4 de WebCGM (le contenu « Intelligence ») utilisant la spécification technique formelle de la définition DTD XML. Il a été suggéré d'adapter les analyseurs XML validants afin de réaliser une validation du contenu des instances WebCGM (soit via une modification des lecteurs, soit via une transformation du contenu intelligent de l'instance WebCGM).

<!-- To document the structure of the CGM Version 4      -->
<!-- content of WebCGM 2.0 the following DTD fragment    -->
<!-- has been developed.                                 -->
<!--                                                     -->
<!-- PICBODY is included in this DTD fragment for        -->
<!-- purposes of demonstrating that the layer, grobject, -->
<!-- and para structures can exist within the picture    -->
<!-- body level in a CGM instance. The gdata element     -->
<!-- with its associated cgmprim entity attribute is     -->
<!-- intended to represent the model for CGM data stored -->
<!-- as an external entity.                              -->
<!--                                                     -->
<!-- Note: of the attributes listed below, all           -->

<!-- correspond to APS Attribute elements of CGM, except -->
<!-- the 'ID', which corresponds to the 'id' parameter   -->
<!-- of the Begin Application Structure CGM element.     -->


<!ELEMENT picbody (layer+ | (grobject | para | grnode 
                             | gdata)*)                       >

<!ELEMENT layer (grobject | para | grnode | gdata)*        >
<!ATTLIST layer
  id            ID         #REQUIRED
  layername     CDATA      #REQUIRED
  layerdesc     CDATA      #IMPLIED
  visibility    (on | off | inherit) #IMPLIED
  interactivity (on | off | inherit) #IMPLIED
                                                              >
<!ELEMENT grobject (grobject | para | grnode | gdata)*     >

<!ATTLIST grobject
  id            ID         #REQUIRED
  region        CDATA      #IMPLIED
  viewcontext   CDATA      #IMPLIED
  linkuri       CDATA      #IMPLIED
  screentip     CDATA      #IMPLIED
  name          CDATA      #IMPLIED
  visibility    (on | off | inherit) #IMPLIED
  interactivity (on | off | inherit) #IMPLIED
                                                              >
<!ELEMENT para (subpara | gdata)*                          >
<!ATTLIST para
  id            ID         #REQUIRED
  region        CDATA      #IMPLIED
  viewcontext   CDATA      #IMPLIED
  linkuri       CDATA      #IMPLIED
  screentip     CDATA      #IMPLIED
  name          CDATA      #IMPLIED
  content       CDATA      #IMPLIED
  visibility    (on | off | inherit) #IMPLIED
  interactivity (on | off | inherit) #IMPLIED
                                                              >
<!ELEMENT subpara (gdata)*                                 >
<!ATTLIST subpara
  id            ID         #REQUIRED
  region        CDATA      #IMPLIED
  viewcontext   CDATA      #IMPLIED
  linkuri       CDATA      #IMPLIED
  screentip     CDATA      #IMPLIED
  name          CDATA      #IMPLIED
  content       CDATA      #IMPLIED
  visibility    (on | off | inherit) #IMPLIED
  interactivity (on | off | inherit) #IMPLIED
                                                              >
<!ELEMENT grnode (grobject | para | grnode | gdata)*       >
<!ATTLIST grnode
  id            ID         #REQUIRED
                                                              >
<!ELEMENT gdata EMPTY                                      >
<!ATTLIST gdata
  cgmprim       ENTITY     #REQUIRED                          >

Remarque : L'emploi de XML pour exprimer le modèle de contenu de WebCGM implique qu'un attribut particulier ne peut avoir qu'une instance au plus au sein d'une instance APS particulière. Ce n'est pas le cas et les règles normatives sont définies dans les sections 3.2.2.1 à 3.2.2.10.

3.4 WebCGM et l'élément object

Le seul moyen normalisé d'appeler des images CGM directement dans des documents HTML est par le biais de l'élément object, en utilisant les attributs data pour le fichier CGM et type pour indiquer le type MIME complet. La déclaration minimale pour ajouter une image CGM dans un document serait :

Les autres attributs HTML 4.01 utilisables avec la balise object comprennent align, border, hspace, id, name et vspace. L'utilisation des attributs align, border, hspace et vspace n'est seulement permise qu'en mode Transitional HTML 4.01, pas Strict HTML 4.01.

Les attributs classid, codebase, declare, shapes, usemap, codetype et archive sont interdits. Un contenu utilisant WebCGM ne devra pas appeler directement le code susceptible de l'afficher.

Les attributs relatifs à des événements (onclick,...,onmouseover) sont permis mais leurs effets sont indéfinis dans cette version de WebCGM. À la place, le DOM de WebCGM offre une méthode addEventListener pour ajouter des guetteurs d'événements aux documents WebCGM.

Les attributs accesskey, alt, class, dir, lang, longdesc, standby, style, tabindex et title sont permis mais n'ont pas d'effets définis sur les visualisateurs CGM et sur l'affichage des images CGM. Utilisés pour améliorer l'accessibilité, ils peuvent aussi affecter la présentation d'un texte de remplacement de l'élément object.

L'élément object peut contenir des éléments param optionnels, ce qui permet de passer des données supplémentaires à l'objet cible par HTML. Les éléments param suivants sont définis et permis pour WebCGM. Chaque élément param se présente sous forme d'un nom suivi des valeurs admises (après le « : ») et d'une description. Les noms et valeurs admissibles sont insensibles à la casse, à la seule exception de la valeur du paramètre nommé onload (qui identifie la fonction de gestion d'événements du script, représentée ci-dessous par « <eventHandlerName(evt)> », à invoquer lors d'un événement de type onload).

onload: <eventHandlerName(evt)>

L'utilisateur fournit le nom d'un gestionnaire d'événement que le visualisateur invoquera à la survenue de l'événement « onload ». Cet élément param et ce descripteur permettent aux développeurs de scripts de manipuler le DOM de WebCGM au point où l'agent utilisateur, ayant entièrement analysé la balise object et ses descendants, est prêt à rendre l'objet à l'écran.

EXEMPLE :

<script type="application/ecmascript">
<![CDATA[
function myHandler(evt) {

    // effectue des appels de manipulation DOM...
}
]]>
</script>

[...]

<object data="xxx.cgm" type="image/cgm;Version=4;ProfileId=WebCGM" width="200" height="100">
    <param name="onload" value="myHandler(evt);"/>
</object>

fixed: No | Yes

Désactive ("Yes") ou active ("No") les commandes d'agrandissement et de panoramique de l'utilisateur du visualisateur. Cela n'affecte pas la navigation dans les images par d'autres moyens, tels que les comportements d'objets dans les fragments IRI. La valeur par défaut est "No". Pour la valeur "Yes", les visualisateurs ne présenteront pas d'options de barres de défilement et d'agrandissement, lesquelles seraient normalement offertes.

background: Enable | Disable

Déclare si l'image CGM devra être dessinée avec sa couleur d'arrière-plan normale, telle qu'elle est donnée dans l'image CGM ("Enable"), ou si la couleur d'arrière-plan de l'image devra être supprimée ("Disable"), permettant ainsi à la couleur ou à l'image d'arrière-plan de la page HTML de transparaître. La valeur par défaut est "Enable". Remarque : La couleur d'arrière-plan de l'image est soit celle par défaut, soit celle définie explicitement par l'élément BACKGROUND COLOUR dans l'image CGM.

viewport: topx topy botx boty

Donne une zone de visualisation de l'image CGM (une partie de l'image) à afficher. Les valeurs sont celles des angles gauche supérieur et droit inférieur de la sous-image. Les unités sont soit dans les coordonnées de l'appareil virtuel (VDC) (Virtual Device Coordinates) de l'image CGM, soit un pourcentage de l'élément VDC EXTENT de l'image (que la valeur soit explicite ou par défaut) si la valeur est suivie d'un signe pourcentage « % ». Cette facilité permet d'afficher des parties différentes de l'image CGM à afficher, à des échelles différentes et à des endroits différents dans le document. La valeur par défaut est la totalité de VDC EXTENT. Remarque : L'utilisation de viewport peut engendrer des conflits avec certaines options (par exemple, les comportements d'objets qui sélectionne effectivement une sous-image via un attribut APS viewcontext dans l'image CGM) dans un fragment IRI sur l'attribut data de l'élément object. En cas de conflit, la définition de viewport sera prépondérante.

Le paramètre viewport est déconseillé et sera peut-être supprimé dans une future version de ce profil.

mapping: fit | fill
halign: top | middle | bottom
valign: left | middle | right

Chaque image CGM a un rapport hauteur/largeur fixe, déterminé par l'élément VDC EXTENT, qui ne concordera peut-être pas à celui défini par les attributs height et width spécifiés sur la balise object. On peut utiliser ces trois paramètres pour indiquer où et comment placer l'image CGM dans la fenêtre indiquée par la balise object. La valeur "fit" définit une mise à l'échelle isotrope de l'image (ou de la sous-image) de sorte qu'une dimension tienne exactement dans la fenêtre, il restera un espace non dessiné dans la fenêtre dans une dimension si les rapports hauteur/largeur ne correspondent pas. Auquel cas, la prise en charge de l'espace en trop est défini par les valeurs de halign (si l'espace en trop est dans la dimension horizontale) et de valign (si l'espace en trop est dans la dimension verticale). La valeur "fill" définit une mise à l'échelle isotrope afin que la fenêtre soit remplie dans les deux directions ; si les rapports hauteur/largeur ne correspondent pas, une partie de l'image sera rognée aux limites de la fenêtres. Auquel cas, les attributs halign et valign définissent quelle partie de l'image est montrée (et quelle partie est masquée) dans la dimension à rogner.

Les valeurs par défaut sont "fit", "middle", "middle", respectivement.

Ces paramètres diffèrent de l'attribut align de l'élément object, lequel sert à indiquer où l'élément object se place dans le document. On pourrait l'exprimer ainsi avec des éléments param :

<param name="halign" value="middle" />
<param name="valign" value="middle" />

Les figures n° 5 et 6 montrent les différents effets obtenus pour "fit" et "fill" avec les différents alignements.

Figure n° 5. Les effets de "fit"

Figure n° 6. Les effets de "fill"

Retour au début du chapitre