6

Module de base: fonctionnalités minimales et obligatoires de HyTime

Le module de base sert à configurer une application HyTime, ainsi qu'à définir l'environnement de l'hyperdocument décrit par la DTD. Il possède également des fonctionnalités optionnelles destinées à mettre en œuvre des fonctionnalités particulières.

6.1 Notion d'objet

HyTime est basé sur la notion d'objet. Ceci n'est pas sans rapport avec les techniques de programmation orientées objet, implémentées aujourd'hui dans des langages tels que Smalltalk ou C++. La relation exacte que HyTime, ainsi que SGML, entretiennent avec la notion d'objet en programmation, est actuellement analysée au sein du groupe de travail SWG SGML du WG8 de l'ISO qui s'est fixé pour objectif la définition d'un modèle abstrait englobant les concepts mis en œuvre par SGML (et HyTime) dans le cadre d'une révision de la norme SGML. Cette question doit faire l'objet d'une élaboration, et il serait prématuré de tenter aujourd'hui une définition globale de ces concepts. Il apparaît néanmoins clair qu'il existe une convergence certaine — et non fortuite — entre l'approche orientée objet et HyTime, qui se traduit notamment par le fait que le langage C++ notamment se prête à la réalisation d'applications HyTime.

Un objet dans HyTime doit être compris comme un ensemble de données qui représente une information, de toute nature (elle peut être textuelle, graphique, sonore ou un mélange de ces formes d'information). Un document entier peut ainsi être considéré comme un objet. Le document peut être également éclaté en objets plus élémentaires. Ce point de vue permet la modularité dans la gestion des documents électroniques.

La représentation des objets dans HyTime est basée sur l'utilisation de SGML. HyTime reprend intégralement la distinction faite par SGML entre trois niveaux de représentation: éléments, attributs et entités. Les éléments sont les blocs élémentaires constituant l'arbre du document. Les éléments peuvent contenir des données, inclure des sous-éléments, ou être composés des deux à la fois. Les attributs sont des propriétés qui qualifient un élément donné sans ajouter une information supplémentaire de structure. Par exemple, un texte multilingue, constitué de paragraphes en différentes langues, peut être décrit en SGML moyennant un attribut langue portant sur l'élément paragraphe et qui en précise la langue^[1]. Enfin, le troisième type d'information est celui qui est regroupé dans un bloc appelé "entité" (voir chapitre 5).

Si HyTime est basé sur SGML pour ce qui est de la représentation des objets, il enrichit SGML par des possibilités supplémentaires d'identification des objets. Pour identifier des objets SGML, il faut que ces objets aient été nommés par un identificateur unique. HyTime reprend cette fonctionnalité, mais en ajoute d'autres. En effet, il est possible d'identifier des objets par leur position dans l'espace et dans le temps. Avec HyTime, la synchronisation d'événements est considérée comme formellement équivalente à l'alignement spatial d'objets. Il est donc possible dans HyTime d'identifier des objets qui ne possèdent pas d'identificateurs, mais qui sont adressables de manière univoque moyennant une procédure d'adressage.

6.2 Déclarations

Elles portent sur la déclaration de mise en oeuvre de HyTime, la version de HyTime utilisée, les modules présents.

6.2.1 Mise en œuvre de HyTime

Le module de base de HyTime contient l'ensemble des fonctionnalités minimales utilisables dans toute application HyTime. La conformité avec HyTime apparaît dans le paramètre APPINFO de la déclaration SGML^[2]. La syntaxe utilisée est:

APPINFO HyTime

si l'on utilise la méta-DTD fournie avec la norme. Si l'on utilise une autre méta-DTD, la syntaxe à utiliser est:

APPINFO HyTime=préfixe, noms

où préfixe doit être remplacé par le nom de préfixe et noms doit être remplacé par les noms d'attributs utilisés. Par défaut, écrire

APPINFO HyTime équivaut à :

APPINFO HyTime=HyTime, HyNames

6.2.2 Version de HyTime

Elle indique la version utilisée ainsi que la limite des nombres utilisés dans les mesures de toute quantité apparaissant dans le document. Ce nombre (HYQCNT) s'exprime en puissance de 2. Par défaut, il vaut 32, ce qui signifie que les quantités présentes dans le document ne peuvent excéder 2³².

<?HyTime VERSION "ISO/IEC 10744:1992" HYQCNT=32 >

Modules utilisés

Cette partie de la déclaration concerne les modules utilisés ainsi que les fonctionnalités optionnelles de chacun de ces modules. Certaines options pourront également être être exprimées ici, par exemple le nombre maximal de systèmes d'axes dans le module d'agencement.

<?HyTime MODULE sched manyaxes=3 >

Les modules doivent être déclarés selon leur désignation normalisée:

- base (module de base)

- measure (module de mesure)

- locs (module adressage de lieux)

- links (module hyperliens)

- sched (module d'agencement)

- rend (module d'exécution).

La liste des options possibles pour chaque module est précisée dans le texte de la norme HyTime, à la fin de la section consacrée à chaque module (clauses 6.8, 7.5, 8.8, 9.3, 10.9 et 11.4).

6.3 Document HyTime

6.3.1 La forme architecturale HyDoc

Il s'agit de la forme architecturale "document HyTime", qui englobe l'ensemble du document. Elle est faite d'une forme de type élément et d'une forme de type attribut^[3]:

<!element HyDoc - O (%HyBrid;)* +(%loc;|%link;|%resorce;)^[4] >

<!attlist HyDoc HyTime NAME HyDoc

id ID #IMPLIED

boslevel NUMBER #IMPLIED

unmspace (unified|separate) separate

docmdu CDATA #FIXED " "

La déclaration d'élément signifie que l'élément HyDoc peut être constitué de très nombreux éléments.

L'entité %HyBrid; est déclarée ainsi:

<!ENTITY % HyBrid ‑‑ HyBrid content (for use in content models) ‑‑

"fcs|HyBrid|sHyTime|#PCDATA"

Le modèle de contenu signifie que l'élément HyDoc peut contenir un mélange d'espaces finis de coordonnées, d'éléments HyBrid (passage HyTime - non HyTime), d'éléments pour lesquels le traitement HyTime est interrompu (sHyTime) ainsi que de caractères parsés SGML (#PCDATA).

L'élément HyDoc peut également contenir à n'importe quel niveau de l'arborescence, des éléments adresses de lieux, représentés par l'entité %loc;, des éléments liens, représentés par l'entité %link;, ainsi que des éléments divers appartenant à l'entité %resorce;.

6.3.1.1 L'entité %loc;

<!ENTITY % loc

6.3.1.2 L'entité %link;

<!ENTITY % link "clink | ilink">

Le détail de chacune des formes architecturales dont la liste figure ici sera présenté respectivement aux chapitres 8 (Module d'adressage) et 9 (Module hyperliens)

6.3.1.3 L'entité %resorce;

<!ENTITY % resorce -- Resource architectural forms: all modules --

"(%resbase;)|(%resmeas;)|(%resschd;)|(%resrend;)">

%resorce;

%resbase;

%resmeas;

%resschd;

%resrend;

activity

dvlist

desctab

lexmodel

lexord

propdef

qltn

qpn

dimspec

extent

extlist

dimref

markfun

measure

axis

exrecon

calspec

mallobj

rendrule

batrule

modrule

wandrule

wndpatch

modpatch

La forme développée de la forme architecturale de type élément HyDoc est donc:

<!element HyDoc ‑‑ HyTime document element ‑‑

‑ O (%HyBrid;)* +(%loc;|%link;|%resorce;) >

<!element HyDoc - O

( "fcs|HyBrid|sHyTime|#PCDATA")

(clink|ilink)) |

Les attributs portant sur l'ensemble du document sont au maximum de 5.

Le premier attribut, HyTime, signifie simplement que l'élément qui sera construit se rattache à la forme architecturale HyDoc. Dans les DTDs, le nom du document sera en effet différent. Supposons que l'on crée un document appelé "mondoc". Dans ce cas, la première ligne de la déclaration d'attribut dans la DTD devient:

<!ATTLIST mondoc HyTime NAME HyDoc .

Le deuxième attribut, id, signifie que l'on peut identifier le document par un identificateur unique.

Le troisième attribut, boslevel, est un nombre qui indique le niveau de délimitation du document considéré comme un ensemble délimité d'objets.

• Si boslevel = 0, cela signifie que le document n'est pas délimité, et que toutes les références vers des documents extérieurs seront prises en considération dans l'hyperdocument global.

• Si boslevel = 1, seul la racine est considérée dans l'ensemble d'objets.

• Si boslevel =2, la racine est prise en compte ainsi que le niveau de résolution suivant.

• Si boslevel =3, la racine ainsi que les deux niveaux de résolution sont prises en compte.

• Etc.

Le quatrième attribut, unmspace, indique si les identificateurs et les entités sont considérés comme appartenant à un même espace des noms ("unified") ou comme appartenant à des espaces de noms séparés ("separate").

Le cinquième attribut, docmdu, (document measurement domain unit) indique l'unité de mesure utilisée (voir chapitre 7, Module de mesure, pour plus de détails.)

6.3.2 La forme architecturale HyBrid

Le fait que l'on puisse utiliser des objets d'information HyTime ou non-HyTime se déclare moyennant une forme architecturale appelée HyBrid (HyTime/non-HyTime bridge element), qui peut contenir pratiquement toute autre forme architecturale. Cet élément doit cependant être systématiquement déclaré dans les DTDs, afin de permettre l'inclusion d'éléments de toute nature.

<!element HyBrid -O (%HyBrid;)* +(%loc;|%link;) >

L'élément HyBrid contient l'entité %HyBrid; . La forme développée de cette entité aide à comprendre ce dont elle est constituée, et en même temps permet un premier aperçu de la richesse des formes architecturales contenues dans la méta-DTD de HyTime.

L'entité %HyBrid; contient l'ensemble des formes architecturales des modules de base, de mesure, d'agencement et d'exécution. Les modules d'adressage de lieu et hyperliens apparaissent sous la forme d'inclusions, qui sera explicitée par la suite.

<!ENTITY % HyBrid -- HyBrid content (for use in content models) --

"fcs|%resorce;|HyBrid|nHyTime|#PCDATA"

D'autre part, l'élément HyBrid peut se contenir lui-même. Il peut également contenir des éléments non-HyTime (nHyTime), qui acceptent n'importe quel contenu^[5], ainsi que des données non structurées (#PCDATA).

Les formes architecturales appartenant aux modules adressage et hyperliens apparaissent sous forme d'inclusion, autrement dit elles peuvent être affectées à tout élément appartenant à la sous-structure.

La forme entièrement développée de l'élément HyBrid s'écrit donc:

<!element HyBrid -O

(fcs|

HyBrid|nHyTime|#PCDATA)*

L'élément HyBrid est utilisé dans la méta-DTD HyTime comme modèle de contenu de certains éléments. Cela permet d'accepter pour cet élément des contenus très divers et très ouverts. Le processus d'écriture d'une application HyTime consiste à partir de la méta-DTD HyTime et de la contraindre afin qu'elle réponde à des spécifications plus précises. Le fait que la méta-DTD HyTime soit extrêmement générale et donc très ouverte dans ses possibilités d'application correspond à une volonté délibérée de la part des auteurs de la norme, qui en aucun cas n'ont souhaité orienté les utilisateurs vers des solutions précises. L'une des conséquences en matière de conception de DTDs HyTime est que l'on aura intérêt, dans la mesure du possible, à concevoir une DTD comme sous-ensemble de celle dérivant des formes architecturales fournies dans ISO/IEC 10744:1992. Ceci a pour effet de rendre compatible les documents ainsi produits avec les logiciels développés en conformité avec la méta-DTD 10744.

6.4 Attributs de données

Le module de base définit les attributs communs (voir chapitre 5) qui sont les suivants:

all-id identification

all-lex types lexicaux

all-ref niveau de résolution des références

all-bits taille d'un élément

all-dvl valeurs par défaut d'attributs

all-desc texte descriptif

all-act politique d'historique d'activité

all-qual noms qualifiant les propriétés

6.5 Mécanismes d'identification

L'identification d'un élément est définie par la forme architecturale de type attribut commun all-id. Cette forme contient la possibilité d'utiliser le mécanisme ID de SGML. Il permet en outre d'identifier la notation dans laquelle le contenu d'un élément est représenté. Il est également possible d'identifier un élément directement par son contenu, avec l'attribut conloc qui fait référence à la fonctionnalité #CONREF de SGML. La validité du contenu d'un élément peut être déclarée en fonction du contexte, avec l'attribut context. Il est également possible de déclarer des noms d'attributs qui remplacent ceux de la méta-DTD HyTime. Dans ce cas, les noms ayant été déclarés comme substitués seront remplacés par les noms créés par le concepteur de l'application.

<!attlist all-id id ID #IMPLIED

notation NAME #IMPLIED

delims CDATA #IMPLIED

conloc IDREFS #CONREF

context (context|ncontext) ncontext

HyNames CDATA #FIXED ""

6.6 Types lexicaux

Le module de base contient les règles précises d'écriture des différents éléments et attributs intervenant dans les DTD. Certaines formes architecturales contiennent sous la forme de "commentaires conventionnels" les indications lexicales. L'attribut all-lex défini dans le module de base s'applique à tous les autres cas. Les noms des attributs doivent être uniques. Les règles lexicales s'appliquent de la même façon aux contenus informationnels. La norme HyTime contient un type d'élément modèle lexical ainsi qu'une notation de contenu informationnel correspondante, qui forment tous les deux HyLex^[6].

<!attlist all-lex lextype CDATA #FIXED "" defined --

lextypgi NAMES #FIXED in-DTD

L'attribut lextype permet de redéfinir les types lexicaux autorisés dans les valeurs d'attributs. L'attribut lextypgi permet de redéfinir les types lexicaux utilisés pour définir les identificateurs génériques des éléments.

Les modèles lexicaux sont représentés par la forme architecturale lexmodel.

<!element lexmodel - O (%HyBrid;)* >

<!attlist lexmodel HyTime NAME lexmodel

ltn NAME #REQUIRED

lexord CDATA #IMPLIED

boundary (sodeod|sodiec|isceod|isciec|inmodel) sodeod

L'élément lexmodel peut être formé de pratiquement n'importe quel élément (voir plus haut, HyBrid). Les attributs spécifiques définis ici sont:

• ltn, nom de type lexical.

• lexord, définition d'ordre lexicographique (voir plus bas)

• boundary, qui définit les contraintes de frontières, dans le domaine spécifié, pour un modèle qui satisfait aux conditions suivantes:

— sodeod. La correspondance doit se faire du début à la fin du domaine.

— sodiec. La correspondance doit se faire au début du domaine, mais pas nécessairement jusqu'à la fin.

— isceod. La correspondance doit se faire à la fin du domaine, mais pas nécessairement depuis le début.

— isciec. La correspondance peut se faire n'importe où à l'intérieur du domaine.

— inmodel. Les contraintes de frontières sont explicitées à l'intérieur du modèle.

6.6.1 Classement lexicographique

Le module de base permet de définir un ordre de classement lexicographique, à l'aide de l'élément lexord qui contient des clés de tri, appelées "graphèmes". Cette fonctionnalité peut être utilisée pour le traitement de données multilingues, sachant que l'ordre de classement peut différer d'un pays à l'autre et que l'ordre de classement basé sur la seule valeur codée des caractères ne correspond pas aux usages. Plusieurs ordres de classement sont possibles, selon par exemple que l'on tient compte ou que l'on ignore les espaces entre les mots.

<!element lexord - O (grapheme+) >

<!attlist lexord HyTime NAME lexord

id ID #REQUIRED>

<!element grapheme - O (%HyBrid;)* >

<!attlist grapheme HyTime NAME grapheme

gs CDATA #REQUIRED

gck NUMBERS #IMPLIED >

gs signifie "grapheme string", gck signifie "grapheme comparison key". Ceci peut être utilisé par exemple pour insérer la chaîne "ll", utilisée dans certaines langues en début de mot, dans l'ordre alphabétique entre les lettres l et m. Ceci s'exprime ainsi :

...

...

La première ligne signifie que la lettre a est la première dans l'ordre alphabétique. Elle est suivie par b, etc. La lettre l est la douzième de l'alphabet, elle est suivie par le graphème ll, qui s'intercale avec m, et les autres lettres ont une valeur de classement augmentée de 1.

6.7 Résolution des références

Le mécanisme utilisé par SGML pour décrire les renvois à l'intérieur d'un document s'appuie sur les attributs ID et IDREF. ID est un identificateur unique qui qualifie un élément, IDREF est ce qui permet d'y faire appel. Ce mécanisme est utilisé par exemple pour les références croisées (que l'on a l'habitude de voir apparaître dans les documents imprimés sous la forme: "voir chapitre X", ou "voir page Y"). SGML permet de donner un nom unique au chapitre puis d'y faire référence, indépendamment du numéro qui pourra apparaître sur la version finale si elle est imprimée.

HyTime étend le mécanisme ID/IDREF à des documents multiples. La référence peut avoir lieu vers un lieu situé dans un autre document. Elle peut également être indirecte, car il est possible de faire appel à un lieu dans le document qui n'a pas été explicitement identifié comme cible de la référence, grâce aux possibilités fournies par le module d'adressage de lieux.

La forme architecturale de type attribut commun, all-ref, permet de préciser les caractéristiques globales du contrôle des références.

<!attlist all-ref refrange CDATA #FIXED "#ALL I"

reflevel CDATA #IMPLIED

reftype CDATA #FIXED "#ALL #ANY"

Elle comprend trois attributs:

6.7.1 Portée d'une référence

Le premier, refrange, permet de préciser si les références à des identificateurs sont :

- directes (dans le même document), auquel cas on peut en outre indiquer que les références se situent en amont,

- indirectes: tel est le cas lorsqu'on fait référence à un élément qui ne possède pas d'identificateur de référence mais qui est identifiable par sa position dans le document moyennant les mécanismes d'adressage des lieux (par exemple: "voir deux paragraphes plus loin"),

- externes: il s'agit alors de références à un lieu situé dans n'importe quel autre document (ou sous-document).

6.7.2 Niveau de résolution d'une référence

Le deuxième, reflevel, concerne la limite à laquelle on souhaite arrêter le processus de résolution des références. Une référence peut en effet appeler une autre référence, qui elle-même en appelle une autre, etc. Ce processus peut être long à traiter, si l'hyperdocument est important. Il est donc possible pour cette raison de l'arrêter à partir d'un certain niveau de résolution.

6.7.3 Type d'élément référence ID

Le type d'élément référence ID, reftype, précise les règles à observer lorsqu'on écrit les noms d'identificateurs.

6.8 Taille d'un élément

La taille d'un élément peut être spécifiée par l'attribut commun all-bits. On déclare le nombre de caractères (ou plus précisément de combinaisons de bits) maximal que doit contenir un élément, ainsi que les éventuels sous-éléments dont il est composé. Cette fonctionnalité n'a pas d'effet sur le contrôle de validité (parsing), mais peut être utilisé pour accroître les performances de l'application.

<!attlist all-bits bitskip NUMBERS #IMPLIED >

6.9 Valeurs par défaut

Le fait d'assigner à des attributs des valeurs par défaut permet de récupérer directement des fichiers SGML et de les rendre compatibles avec HyTime. Il suffit en effet de déclarer que tel attribut correspond à telle forme architecturale qui a une valeur par défaut spécifiée, pour que cette valeur lui soit automatiquement ajoutée, sans qu'il soit nécessaire d'intervenir dans l'instance de document proprement dite.

Les valeurs par défaut sont associées aux éléments et aux attributs au moyen de l'attribut commun "all-dvl".

<!attlist all-dvl subdvl IDREFS #IMPLIED

sibdvl IDREFS #IMPLIED

• L'attribut subdvl (subelement default value list) contient les valeurs par défaut des attributs qui apparaîtront dans les sous-éléments de l'élément spécifié.

• L'attribut sibdvl (sibling default value list) contient les valeurs par défaut des attributs qui apparaîtront dans les descendants de l'élément spécifié.

Les valeurs par défaut sont précisées pouir chaque élément dans la forme architecturale de type élément dvlist. Cette liste permet de préciser pour chaque niveau d'élément le nom de l'identificateur générique (de l'élément) auquel elles s'appliquent (attribut dvgi). Il est également possible de "pré-empter" certaines valeurs par défaut (attribut preatts).

<!element dvlist - O (#PCDATA) >

<!attlist dvlist HyTime NAME dvlist

id ID #REQUIRED

dvgi NAMES #IMPLIED

preatts NAMES #IMPLIED

6.10 Texte descripteur

Le fait de disposer de texte descripteur permet de gérer dans un tableau les éléments fréquemment répétés dans un document. La différence entre le texte descripteur et une entité est que l'entité contient explicitement le contenu à substituer, alors que le texte descripteur décrit, comme son nom l'indique, une opération à effectuer afin de développer le texte dans son ensemble. Ici, texte est entendu au sens large d'information. Ainsi, les séquences logiques entrant dans un texte descripteur peuvent être des macros, par exemple ou encore des phrases musicales possédant un certain algorithme — le stockage de l'algorithme étant plus économique que le stockage de l'ensemble des données produites.

<!attlist all-desc desctxt CDATA #CONREF

desctab IDREFS #CURRENT

Trois formes architecturales de type élément complètent cette liste d'attributs. Il s'agit du tableau descripteur (desctab), du texte descripteur (desctxt), des définitions de texte descripteur (descdef).

Le tableau descripteur associe les chaînes de caractères contenant le texte descripteur aux définitions.

<!element desctab - O (desctxt, descdef)+ >

<!attlist desctab HyTime NAME desctab

id ID #REQUIRED >

<!element desctxt O O (#PCDATA) >

<!attlist desctxt HyTime NAME desctxt >

<!element descdef O O (%HyBrid;)* >

<!attlist descdef HyTime NAME descdef >

6.11 Politique de gestion et d'historique des accès ("Activity tracking policy")

HyTime dispose d'un attribut commun permettant de gérer le traçage de l'activité dans un document de manière très fine. Cet attribut, appelé all-act, définit l'activité qui pointe vers les éléments de la forme activity.

<!attlist all-act activity IDREFS #IMPLIED >

Chaque activité est définie pour un élément donné par la forme architecturale activity:

<!element activity - O (%HyBrid;)* >

<!attlist activity HyTime NAME activity

id ID #REQUIRED

actypes NAMES access

Il est possible en effet de définir pour chaque élément une valeur de l'attribut actypes parmi les six valeurs suivantes:

- create: l'objet a été créé.

- modify: l'objet a subi une modification.

- link: un lien vers l'objet a été créé.

- access: un accès à l'objet a été effectué.

- unlink: un lien a été détruit.

- delete: l'objet a été détruit.

De nombreuses applications peuvent tirer parti de cet attribut. Il est possible par exemple pour un éditeur ou un propriétaire de document de gérer l'accès et la tarification en fonction du nombre d'objets lus, imprimés. Cet attribut permet la traçabilité de la création d'un document. Il est possible ainsi de savoir qui a créé tel ou tel élément, qui l'a modifié, quand cela a été fait, etc. Le traçage d'activité est une solution aux problèmes de copyright électronique, et permet de mettre en place une politique de gestion de versions; par exemple, la valeur delete de l'attribut activity permet de préserver un élément qui n'a plus cours dans le document mais qui peut tout de même avoir été référencé par des versions précédentes. C'est le cas par exemple d'un texte de loi qui a été remplacé par un nouveau, mais auquel on peut continuer à faire référence, ne serait-ce que pour des raisons historiques.

La fonctionnalité Activity tracking policy est extrêmement générique et peut donc être appliquée à de nombreux domaines. La norme en fournit quelques exemples: contrôle de l'intégrité des références, sécurité, groupware, protection de la propriété intellectuelle, didacticiels, contrôle de la qualité d'un manuel de maintenance. Ce dernier point indique que l'on peut utiliser la valeur access avec les fonctionnalités d'agencement de HyTime pour connaître le temps passé par un technicien sur chaque étape d'une procédure. Cette information peut être exploitée pour tester la clarté de l'écriture du manuel et en général sa qualité, ainsi que pour savoir si le technicien a passé suffisamment de temps pour que l'on soit assuré que le travail ait été correctement effectué. Le traçage d'activité permet également de savoir si toutes les étapes d'une procédure ont été passées en revue. Un autre exemple est celui du "statut" dans la norme AECMA 1000D, qui permet de noter la date d'édition du module de données. On peut envisager de gérer cette information à l'aide de la forme architecturale "activity tracking policy" de HyTime. Bien d'autres applications peuvent être conçues qui mettent en œuvre cette fonctionnalité^[7]. L'attribut activity tracking montre la puissance de HyTime et enrichit le contenu informationnel de données qui jusqu'ici appartenaient aux logiciels d'application.

6.12 Gestion des entités

HyTime permet de regrouper les données déclarées dans plusieurs entités à l'intérieur d'un même conteneur ainsi que de retrouver ces attributs à l'intérieur du conteneur. Cette fonctionnalité étend les déclarations de notation de SGML^[8], qui permettent de passer des paramètres au programme chargé d'interpréter les notations (par exemple des graphiques).

La forme architecturale de type liste d'attributs sbento définit une notation de contenu de données destinée à la création de conteneurs:

<!attlist #NOTATION sbento HyTime NAME sbento

unitsize NUMBER 8 >

L'attribut unitsize définit la granularité pour les objets contenus. La valeur par défaut, 8, signifie par exemple que l'on utilise des caractères codés sur 8 bits comme granules élémentaires de stockage des objets.

La forme architecturale de type liste d'attributs, any-dcn, est composée d'attributs de données s'appliquant à tout élément et qui répondent aux objectifs suivants:

- positionner une entité à l'intérieur d'un conteneur;

- fournir les données nécessaires à la validation de l'intégrité du processus de modification;

- spécifier les différentes représentations possibles d'une entité;

- spécifier toute information utilisable par une application pour interpréter et accéder aux données contenues dans l'entité.

<!attlist #NOTATION any-dcn insbento CDATA #IMPLIED

modgen NUMBERS #IMPLIED

altreps NAMES #IMPLIED

superdcn NAME #IMPLIED

template NAME #IMPLIED

methods CDATA #IMPLIED

degrade CDATA #IMPLIED

encoding NUMBERS "8 12"

HyNames CDATA #FIXED "" >

• L'attribut insbento précise la position dans le conteneur.

• L'attribut modgen permet de garder la trace des niveaux de modification afin de préserver l'intégrité des données.

• L'attribut altreps permet d'identifier d'autres notations équivalentes.

• L'attribut superdcn informe sur la notation dont est originaire la notation employée.

• L'attribut template permet de préciser le contexte de parsing, ou de traitement, par exemple un ensemble de macros utilisées dans les données.

• L'attribut methods permet d'utiliser des techniques de programmation orientée objet en précisant les méthodes utilisatbles par une application pour accéder aux données encapsulées dans l'entité.

• L'attribut degrade permet de préciser ce qu'il faut faire au cas où l'application n'est pas en mesure d'interpréter l'entité.

• L'attribut encoding précise les éléments spécifiques à l'encodage pour une plateforme logicielle ou matérielle donnée.

• Enfin l'attribut HyNames permet de substituer des noms forgés par l'utilisateur aux noms des attributs HyTime.

6.13 Propriétés

Les propriétés, identifiables par des applications, peuvent être précisées moyennant la forme architecturale propdef.

<!element propdef - O (%HyBrid;)* >

<!attlist propdef HyTime NAME propdef

pn NAME #REQUIRED

psn NAME #REQUIRED

lex CDATA #IMPLIED

inherent NAME #IMPLIED

dspec CDATA #IMPLIED

deforsyn (def|syn) def >

• L'attribut pn contient le nom de la propriété.

• L'attribut psn déclare le nom de l'ensemble de propriétés.

• Le type lexical de propriété est déclaré dans l'attribut lex.

• L'attribut inherent identifie des spécifications qui peuvent être référencées (par exemple, les normes SGML ou HyTime).

• L'attribut dspec permet de distinguer parmi plusieurs instances d'une même propriété.

• L'attribut deforsyn permet de préciser lorsque deux propriétés ou plus sont exprimées par des synonymes.

Les propriétés, une fois définies par la forme propdef, sont spécifiées par d'autres formes architecturales:

La forme qpn permet de préciser un nom de propriété qualifiée.

<!element qpn - O (pn, spec?)+ >

<!attlist qpn HyTime NAME qpn

id ID #REQUIRED>

La forme pn (nom de propriété) permet d'identifier une propriété appartenant à un ensemble spécifié par l'attribut psn (nom d'ensemble de propriétés).

<!element pn - O RCDATA >

<!attlist pn HyTime NAME pn

psn NAME #IMPLIED >

La forme spec spécifie une autre propriété qualifiée (qpn), un nom de type lexical de propriété (qltn) de l'élément spécifié par l'attribut identificateur générique de modèle lexical (lmgi) ou une valeur de propriété (pval) satisfaisant la même propriété.

<!element spec - O ((qpn|qltn)+|pval) >

<!attlist spec HyTime NAME spec>

<!element qltn - O RCDATA >

<!attlist qltn HyTime NAME qltn

lmgi NAME #IMPLIED >

<!element pval - O RCDATA >

<!attlist pval HyTime NAME pval >

La forme architecturale commune all-qual permet d'omettre le nom d'ensembles de propriétés des noms de propriétés qualifiées, ainsi que des identificateurs génériques des noms de types lexicaux qualifiés.

<!attlist all-qual qpnpsn NAMES #IMPLIED

qltnlmgi NAMES #IMPLIED >

6.14 Formes architecturales définies dans le module de base

6.14.1 Type élément

HyDoc Élément Document HyTime

HyBrid Élément pont HyTime/non-HyTime

nHyTime Élément Non-HyTime

lexmodel Modèle lexical

lexord Définition de classement lexicographique

grapheme Clé de comparaison de graphèmes

dvlist Liste de valeurs par défaut

desctab Table de définition de texte descripteur

desctxt Texte descripteur

descdef Définition de texte descripteur

activity Politique de traçage d'activité

propdef Définition de propriété

qpn Nom de propriété qualifiée

pn Nom de propriété

spec Spécification de propriété

qltn Nom de type lexical qualifié

pval Valeur de propriété

6.14.2 Type liste d'attributs

6.14.2.1 Attributs communs

all-id Identification

all-lex Types lexicaux des valeurs d'attributs ou du contenu des données textuelles

all-ref Contrôle de résolution des références d'identificateurs

all-bits Comptage des combinaisons de bits

all-dvl Attributs de listes de valeurs par défaut

all-desc Attributs de texte descripteur

all-act Politique de traçage d'activité

all-qual Attributs des noms qualifiant

6.14.2.2 Notations

sbento Attribut des notations de contenu informationnel sbento.

any-dcn Attributs communs des notations de contenu informationnel.

[1]. Voir Guide d'utilisation de SGML.

[2]. Voir Guide d'utilisation de SGML, p. 95.

[3]. Dans la suite du texte, la méta-DTD de HyTime est reproduite sans les commentaires conventionnels, dans le but de faciliter la lecture de la structure des déclarations d'éléments et d'attributs. On se reportera au texte de la norme pour les indications complètes de la méta-DTD.

[4]. Le texte présenté ici tient compte des modifications qui ont été proposées par les experts du domaine et qui doivent être prises en compte dans un futur amendement à la norme HyTime. Il s'agit pour la plupart de corrections mineures qui ne modifient pas le contenu de la norme, mais permettent de corriger un certain nombre de détails. On trouvera la liste des corrections recensées en annexe. Par exemple, l'entité %resorce; a été ajoutée à la définition de l'élément HyDoc et a été retirée de l'entité %HyBrid;.

Les définitions originales des éléments HyDoc et HyBrid étaient:

<!ENTITY HyBrid "fcs|%resorce;|HyBrid|nHyTime|#PCDATA"

<!element HyDoc -O (%HyBrid;)* +(%loc;|%link;)

<!element HyBrid -O (%HyBrid;)* +(%loc;|%link;)

Elles doivent être modifiées ainsi:

<!ENTITY HyBrid "fcs|HyBrid|sHyTime|#PCDATA"

<!element HyDoc -O (%HyBrid;)* +(%loc;|%link;|%resorce;) >

<!element HyBrid -O (%HyBrid;)* >.

[5]. Equivalent de NDATA dans SGML.

[6]. Voir ISO 10744:1992, annexe A.

[7]. La conception d'applications génériques fondées sur cette forme architecturale fait l'objet actuellement (octobre 1993) de travaux d'élaboration dans le cadre du groupe chargé d'élaborer des "Conventions d'Application de HyTime" (CApH). Ce groupe appartient au GCARI (Graphics Communication Association Research Institute) et est dirigé par Steven R. Newcomb, l'un des auteurs de HyTime.

[8]. Voir le Guide d'utilisation de SGML, p. 76 et p. 176. Voir également norme ISO 8879:1986, SGML, clause 11.4, p. 50 version française (norme NF EN 28879, décembre 1990), Voir explications complémentaires dans le livre de C. Goldfarb, The SGML Handbook, Clarendon Press, Oxford, 1990.