5

Les constituants de base d'une application HyTime

 

 

5.1 Hyperdocuments: entrée, délimitations, nature des données

 

 

 

Un hyperdocument est considéré dans le contexte HyTime comme le regroupement de plusieurs documents ou de tous autres objets constituant de l'information, reliés selon une structure de réseau. Il peut donc s'agir d'un ensemble de textes, de fichiers présents sur le même site ou d'un ensemble d'objets connectés selon un réseau physique, par exemple un réseau local ou un réseau téléphonique commuté. Autrement dit, l'ensemble d'objets formant un hyperdocument n'est pas nécesssairement formé d'objets tous présents sur le même support (document publié) ou sur un même site. Cette conception de l'hyperdocument est donc beaucoup plus ouverte que la définition d'un hypertexte "classique" qui se limite à un seul document présent. HyTime prend donc en charge la gestion des documents entièrement électronique. La notion de publication perd son caractère figé: œuvre d'auteur aboutie et diffusée, pour être remplacée par une notion de modules d'information vivants présentés à un moment donné selon une ou plusieurs présentations. La notion d'évolutivité et de mise à jour est donc intégrée comme un point de départ, puisqu'il s'agit essentiellement ici d'accéder à des objets informationnels structurés et reliés.

 

Le document devient dans cette optique l'assemblage éphémère d'objets formatés "au vol". Les bases documentaires soumises à des mises à jour rapides peuvent engendrer des documents différents pratiquement à chaque visualisation. Le niveau de granularité des documents peut être extrêmement fin. Un "document"est un assemblage de granules et de liens qui les relient.

 

5.1.1 Document-pivot: le point d'entrée

 

Le point d'entrée dans un hyperdocument se fait dans un document particulier appelé document-pivot. L'hyperdocument est considéré comme conforme HyTime si le document-pivot est une instance de document HyTime. Les autres objets constituant l'hyperdocument ne sont pas nécessairement, eux, des documents HyTime. Il est ainsi possible de récupérer dans un hyperdocument HyTime des documents existants, qui peuvent être par exemple des instances de documents SGML répondant à plusieurs DTDs ou même des documents non structurés. Bien entendu, le détail du niveau de structure influe sur les applications possibles par la suite. Plus un document est structuré, plus l'accès à un élément précis d'information sera aisé, et plus les applications seront riches.

 

5.1.2 Ensemble délimité d'objets

 

Un hyperdocument HyTime regroupe des documents reliés les uns aux autres. HyTime permet de définir la frontière de l'ensemble des objets qui sont destinés à être traités ensemble. Sans cette frontière, rien n'empêcherait que le système des liens puisse s'étendre vers un nombre quasi illimité de documents, rendant alors la gestion difficile voire impossible. HyTime définit ainsi un "ensemble délimité d'objets" (Bounded Object Set, ou BOS) qui forme la frontière de l'hyperdocument. La notion de référence bibliographique de HyTime indique une référence vers un objet externe à l'hyperdocument délimité. Cela correspond au cas où l'on consulte un document sous forme électronique qui forme un ensemble cohérent de liens, et où l'on fait référence par exemple à des documents n'exis­tant que sous forme imprimée. Ce type de référence vers des objets externes à l'hyperdocument est appelé adresse bibliographique. Il s'agit de la transposition à l'hyperdocument de ce qui est utilisé depuis longtemps dans les livres: les références croisées ou renvois internes (du type "voir chapitre 2" ou "voir page 53") sont considérés comme des liens internes à l'hyperdocument, alors que les mentions d'autres documents (du type "voir le Guide d'utilisation de SGML ,  p. Y") sont faites sous la forme de références bibliographiques.

 

 

5.1.3 Entités

 

Pour constituer un hyperdocument, HyTime a recours à la notion classique d'entité déjà à l'œuvre dans SGML, qui permet d'inclure dans un document n'importe quel objet (qui peut être la forme développée d'une abréviation, ou un graphique, ou encore un autre document).

 

 

<!ENTITY % sousdoc  "/graphiques/%g1;" >

                                  │

           ┌──────────────────────┘

           │

<!ENTITY % g1 "/eps/%moteur;" >

                       │ 

             ┌─────────┘

             │

<!ENTITY % moteur "m1" >

 

                  


Le niveau de complexité atteint peut être assez élevé, car des entités peuvent être déclarées à l'intérieur d'autres entités, et les  limites de l'hyperdocument produit peuvent être alors difficiles à maîtriser. Pour ce faire, la forme architecturale HyDoc a un attribut boslevel qui indique le nombre de niveaux de résolution des entités auxquels on doit s'arrêter pour constituer un hyperdocument. Un hyperdocument ayant un boslevel qui vaut 2 sera constitué du document-pivot et des entités de premier niveau. Toutes les autres entités appelées dans les entités de premier niveau seront ignorées.

 

 

5.1.4 Flux des données

 

Les données peuvent être transportées selon le format SDIF (SGML Document Interchange Format), norme ISO 9069[1]. Un document SGML est transféré vers un "compresseur SDIF" qui permet son stockage ou sa transmission, selon ASN.1. Le document peut ensuite être décompressé pour être récupéré sous sa forme SGML d'origine. SDIF est essentiellement adapté à la transmission de données textuelles. Ce format n'est pas obligatoire, il est seulement recommandé par la norme HyTime (voir clause 6.2.4). Toutefois, ce format n'est pas adapté comme format d'échange pour les images animées, le son, ou d'autres parties interactives de documents qui peuvent être échangées sous leur forme interprétée. La norme HyTime ne recommande pas de format précis, dans la mesure où les normes d'encodage d'objets multimédia (JPEG, JBIG, MPEG notamment) n'étaient pas abouties au moment de la publication de HyTime. Il est cependant conseillé d'utiliser les formats de compression normalisés existants afin de préserver une ouverture maximale pour les échanges.

 

 

5.2 Méta‑DTDs

 

 

HyTime contient une méta-DTD, c'est-à-dire un ensemble d'objets préétablis servant à créer des DTDs. Une méta-DTD n'est pas interprétable par une machine. Il s'agit d'un ensemble de règles indiquant comment construire des DTDs. Si l'on décide d'utiliser un élément donné fourni par HyTime, celui-ci possède un certain modèle de contenu et une liste d'attributs parmi lesquels on peut sélectionner ceux qui sont significatifs pour l'application. La méta-DTD présente dans la norme est tout à fait générique. Elle permet donc de créer des DTDs qui couvrent de très nombreux cas possibles. Elle constitue un guide de création de DTDs qui facilite grandement la conception des documents HyTime. Il est toujours possible d'ajouter des éléments non prévus par la méta-DTD de référence, fournie avec la norme.

 

Afin de distinguer les méta-DTDs HyTime des DTDs SGML, on convient d'utiliser des caractères bas de casse (minuscules) dans les méta-DTDs et des capitales (majuscules) dans les DTDs.

 

<!element ...  ---->  méta-DTD

 

<!ELEMENT ...  ---->  DTD

 

 

 

5.3 Formes architecturales

 

 

 

5.3.1 Deux types de formes architecturales

 

Il existe deux types de formes architecturales: les formes de type élément et les formes de type liste d'attributs.

 

5.3.1.1 Formes architecturales de type élément

 

Les formes architecturales de types d'élément ressemblent aux déclarations d'éléments des DTDs SGML. Sur le plan formel, une déclaration d'élément HyTime est identique à une déclaration d'élément SGML, à ceci près que le mot "element" apparaît en bas de casse. Les règles de syntaxe pour les modèles de contenu sont intégralement reprises de SGML. En revanche, les identificateurs génériques ont une sémantique. Par exemple, la ligne suivante:

 

<!element measure - O (granule+)>

 

indique que l'on définit le domaine de mesure utilisé comme un ensemble de granules élémentaires d'information.

 

Une déclaration d'élément est ainsi composée de la façon suivante[2]:

1) "<!element"  introduit toute déclaration d'élément.

 

2) l'identificateur générique, qui est le nom de la forme architecturale de type élément. Dans l'exemple qui précède, l'identificateur générique est "measure".

 

3) les indications de minimisation de balisage (identiques à celles qui sont définies dans SGML). "-" indique que la balise est obligatoire, "O" qu'elle peut être omise. Dans la déclaration précédente "- O" indique donc que la balise de début est obligatoire, alors que la balise de fin peut être omise.

 

4) le contenu de l'élément peut être formé soit d'un contenu déclaré, soit d'un modèle de contenu, qui sont construits de façon identique aux modèles apparaissant dans les DTDs SGML.

 

• Contenu déclaré

Les éléments à contenu déclaré peuvent prendre trois formes différentes:

- CDATA: contenu déclaré "caractères"

- RCDATA: contenu déclaré "caractères substituables"

- EMPTY: contenu déclaré vide

 

• Modèle de contenu

 

Les éléments décrits par un modèle de contenu ont une structure plus ou moins complexe décrite par des indicateurs d'occurrence et de connecteurs. Dans l'exemple précédent, le modèle de contenu "(granule+)" est très simple. Le symbole "+" indique que l'élément granule doit être présent au moins une fois dans l'élément "measure" et qu'il peut être répété un nombre indéterminé de fois. (Les autres symboles d'occurrence possibles sont:

"*", indiquant que l'élément est optionnel et répétable. Il peut donc être absent, ou être répété un nombre indéterminé de fois.

"?", indiquant que l'élément est optionnel.

Quand plusieurs éléments existent dans le modèle de contenu, ils sont séparés par des connecteurs:

"," indique que les éléments se suivent dans l'ordre indiqué;

"&" indique que les éléments sont présents simultanément, mais dans n'importe quel ordre.

"|" indique que l'un ou l'autre des éléments est présent.

Les modèles peuvent être constitués de groupes marqués par des parenthèses.


Ils peuvent également contenir des inclusions ou des exclusions.

 

5) Enfin, la déclaration d'élément se termine par le symbole ">"[3].

 

 

5.3.1.2 Formes architecturales de type liste d'attributs

 

Les éléments HyTime ont une liste d'attributs associée. La liste d'attributs correspondant dans la méta-DTD HyTime à l'élément measure est la suivante:

 

<!attlist measure HyTime   NAME     measure

                  id       ID       #IMPLIED -- Default:none --

                  smu -- Standard measurement unit for domain --

                      -- Constraint: notation name of an SMU.

                     If virtual, it must have a formal public ID

                     of "Virtual Measurement Unit" --

                            NAME     #REQUIRED

>

La liste d'attributs peut soit être reprise intégralement, soit partiellement. On peut également enrichir la liste d'attributs fournie par de nouveaux attributs propres à la DTD spécifique à créer.

 

Les attributs associés à des éléments ont tous comme premier nom d'attribut HyTime.

 

Les attributs peuvent être utilisés soit pour qualifier un élément, soit pour les notations de contenu textuel.

Les formes architecturales de type liste d'attributs sont composées de la façon suivante:

 

a) Comme pour SGML, les listes d'attributs sont introduites par "<!attlist".

 

b) On écrit ensuite le nom de l'élément (l'identificateur générique) auquel se rapport cet attribut, ici measure.

 

c) Chaque ligne est ensuite composée des différents attributs qui composent cette liste. Le nom de l'attribut vient d'abord. Ici, la première ligne contient l'attribut HyTime, la deuxième l'attribut id, la troisième l'attribut smu.

 

d) Le nom d'attribut est suivi par la prescription de valeurs déclarées. La première ligne, par exemple, contient le mot-clé NAME, qui indique que les valeurs possibles respectent la syntaxe de ce qui est considéré comme un nom, notamment que le premier caractère doit être une lettre. Celui-ci peut être suivi de caractères constitutifs du nom, formés de lettres, de chiffres de points ou de traits d'union[4]. La liste complète des noms pouvant figurer dans la prescription de valeurs déclarées d'attributs est :

CDATA

ENTITY

ENTITIES

ID

IDREF

IDREFS

NAME

NAMES

NMTOKEN

NMTOKENS

NOTATION

NUMBER

NUMBERS

NUTOKEN

NUTOKENS[5]

 

e) Ensuite vient la prescription de valeurs par défaut. Ici measure signifie que c'est la valeur par défaut de l'attribut HyTime. #IMPLIED dans la deuxième ligne signifie que l'attribut id est optionnel; le mot-clé #REQUIRED signifie que l'attribut smu est obligatoire.

 

Les valeurs par défaut possibles peuvent également être déclarées comme une liste séparée par des connecteurs "|" ("ou"). Ainsi  "(a|b)" signifie que a ou b peut être choisie comme valeur par défaut posssible.

 

La liste complète des mots-clés de valeurs par défaut possibles est:

 

#FIXED                 attribut fixe

#REQUIRED attribut obligatoire

#CURRENT   attribut en cours

#CONREF               attribut faisant appel au contenu

#IMPLIED             attribut optionnel (calculé par l'application)[6]

 

 

f) Chaque ligne peut contenir des commentaires, notés entre couples de tirets, appelés commentaires conventionnels, qui ont "force de loi". Ce sont des commentaires indiquant comment écrire la DTD.

 

g) La déclaration d'attribut se termine par le signe ">".

 

Ainsi, les formes architecturales peuvent être considérées comme des modes d'emploi pour écrire les DTDs. Le fait de savoir lire la méta-DTD de la norme représente donc une étape majeure pour la création de documents HyTime.

 

Lors de l'écriture d'une DTD, on peut soit reprendre l'intégralité des attributs définis dans la liste, soit seulement certains d'entre eux.

 

Le premier attribut, HyTime, est obligatoire, car il indique le nom de la forme architecturale à laquelle les attributs se conforment.

 

Si la forme définie dans la méta-DTD est reprise intégralement, le nom redouble. C'est pourquoi l'on trouve deux fois le mot "measure"dans la première ligne de la liste d'attributs.

 

Si l'on suppose maintenant que le nom de l'élément n'est plus "measure", mais le mot français "mesure", et que le mot "granule" est remplacé par "grain", on aura:

 

<!ELEMENT   mesure      - O   (grain+)    >

<!ATTLIST   mesure      HyTime      measure

id    ID    #IMPLIED

smu   NAME  #REQUIRED >

 

Le mot "measure" reste inchangé à droite dans la première ligne de la liste d'attributs. Ceci indique que "mesure"est un attribut qui se rattache à la forme architecturale "measure", définie dans la méta-DTD.

 

•Formes architecturales de type liste d'attributs sans éléments associés

 

Il existe dans HyTime des formes architecturales sans nom d'élément correspondant. Elles sont syntaxiquement identiques aux précédentes. Au lieu d'être attachées à un élément unique, elles peuvent être injectées à l'intérieur de plusieurs listes d'attributs correspondant à des éléments différents. Elles sont injectables dans la DTD comme complément des premières, et peuvent se rattacher à certains éléments qui sont précisés sous la forme d'un commentaire. Elles ne commencent donc pas par l'attribut HyTime, mais intègrent dans un commentaire conventionnel commençant par "use:" la liste des éléments auxquels elles peuvent être associées suivent le mot-clé "use".

 

Par exemple la forme architecturale de type liste d'attributs multloc est utilisée à l'intérieur des listes d'attributs des formes architecturales nameloc, dataloc, treeloc, pathloc, listloc, relloc, proploc, notloc et fcsloc. Le fait d'en faire une forme architecturale en tant que telle évite de répéter 9 fois la même information.

 

<!attlist multloc           -- use: nameloc dataloc treeloc pathloc

                                    listloc relloc proploc notloc fcsloc --

                   ordering -- Is ordering of locations significant? --

                            (ordered|noorder) noorder

                   set      -- Make multiple a set by ignoring duplicates --

                            (set|notset) notset

                   aggloc   -- Are multiple locations an aggregate? --

                               (aggloc|agglink|nagg) nagg

>

 

Il existe également dans la DTD des cas où le nom de l'attribut est redoublé et paraît identique à celui de l'élément correspondant. C'est le cas par exemple de exspec:

 

<!attlist exspec            -- use: event proscope modscope --

                   exspec   -- Extent specification --

                            -- Constraint:multiple references concatenated --

                            -- reftype(extlist) --

                            IDREFS   #REQUIRED

>

 

 

En réalité, cette déclaration ne doit pas être confondue avec les déclarations de listes d'attributs se rapportant à un élément. Il n'y a pas ici d'élément nommé exspec. Cette déclaration d'attribut est faite pour être insérée à l'intérieur d'autres déclarations d'attributs et l'attribut exspec vient simplement s'ajouter à la liste des attributs déclarés. Dans l'exemple précédent, l'attribut exspec vient s'ajouter aux listes d'attributs correspondant aux éléments event, proscope et modscope (indiqués à la suite du mot-clé use. Ainsi, par exemple, la forme architecturale proscope s'écrit:

 

<!element proscope -- Projector scope --

                   -- Defines the scope of an event projector

                      as an extent of the unprojected schedule --

                   - O      (projectr) >

<!attlist proscope HyTime   NAME     proscope

                   id       ID       #IMPLIED  -- Default: none --

                            -- exspec attributes --

>

 

la dernière ligne de la liste d'attributs doit être remplacée par la déclaration explicite de exspec. De sorte que l'on obtient pour la liste d'attributs associée à l'élément proscope:

 

<!attlist proscope HyTime   NAME     proscope

                   id       ID       #IMPLIED  -- Default: none --

                   exspec   -- Extent specification --

                            -- Constraint:multiple references concatenated --

                            -- reftype(extlist) --

                            IDREFS   #REQUIRED

>

 

Cette forme architecturale de liste d'attributs séparés évite donc une redondance de l'information dans la méta-DTD. En revanche, dans la DTD, cet attribut doit être répété autant de fois qu'il est nécessaire, à la suite de chaque déclaration d'élément.

 

• Attributs associés à des notations de contenu informationnel[7]

 

Il s'agit ici de l'exploitation d'une fonctionnalité SGML permettant de déclarer une liste de définitions d'attributs par leur contenu d'information. On l'utilise pour déclarer des attributs qui se trouvent à l'intérieur d'une entité[8]. On peut ainsi stocker dans des "conteneurs" plusieurs entités différentes. Il s'agit en quelque sorte d'une table des matières des entités externes utilisées dans un hyperdocument. La forme architecturale de la méta-DTD HyTime s'appelle sbento. Elle provient du terme japonais "bento" qui désigne une boîte séparée en plusieurs compartiments organisés de façon esthétique. Sbento est l'acronyme de "Standard Bento Entity for Natural Transport of Objects" (entité bento normalisée pour le transport naturel des objets)[9].

 

 

5.4 Organisation modulaire de HyTime

 

 

La conception de HyTime en modules séparés permet de concevoir des applications qui ne se conforment qu'à certains d'entre eux.

 

Les modules ont entre eux des relations d'interdépendance partielle.

 

5.4.1 Les six modules

 

HyTime est formé de six modules:

- module de base

- module de mesure

- module adressage de lieux

- module hyperliens

- module d'agencement

- module d'exécution

 

Ces six modules peuvent ne pas être présents simultanément dans une application. Le module de base est le seul requis pour qu'une application puisse être considérée comme conforme HyTime.

 

Le module d'exécution impose la présence du module d'agencement qui lui-même impose la présence du module de mesure. Les configurations possibles sont les suivantes:

 

• module de base seul.

• module de base, module hyperliens.

• module de base, module addressage de lieux.

• module de base, module de mesure.

• module de base, module de mesure, module d'agencement.

• module de base, module de mesure, module d'agencement, module d'exécution.

 

La présence du module d'adressage de lieux permet d'enrichir les fonctionnalités hyperliens et de mesure. On peut donc trouver également les configurations suivantes:

 

• module de base, module hyperliens, module d'adressage des lieux

• module de base, module de mesure, module d'adressage des lieux.

 

Dans le dernier cas, le module de mesure peut également être complété soit par le modules d'agencement, soit par les modules d'agencement et d'exécution.

 

Le contenu de chacun des modules sera présenté dans les chapitres qui suivent.

 

 

5.5 Liste des formes architecturales de la méta-DTD HyTime

 

 

 

 

La liste des formes architecturale est présentée dans l'ordre de leur apparition dans la méta-DTD HyTime.

 

5.5.0.1 Formes architecturales de 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 d'ordre lexicographique

grapheme   clé de comparaison de graphèmes

dvlist       liste de valeurs par défaut

desctab     table de définition de texte descriptif

desctxt     texte descriptif

descdef     définition de texte descriptif

activity   politique de traçage d'activité

propdef     définition de propriété

qpn             nom de propriété qualifié

pn               nom de propriété

spec           spécification de propriété

qltn           nom de type lexical qualifié

pval           valeur de propriété

dimspec     spécification de dimension

marklist   liste de marqueurs d'axes ou d'équivalents

dimlist     liste des spécifications de dimension

extent       étendue

extlist     liste d'étendues agencées

measure     domaine de mesure

granule     granule

dimref       référence de dimension

markfun     function de marqueur

nameloc     adresse de lieu nommé

nmlist       liste de noms

dataloc     lieu défini par coordonnées

treeloc     nœuds d'un arbre (description classique)

pathloc     nœuds d'un arbre (description matricielle)

listloc     nœuds d'une liste

relloc       nœuds identifiés relativement à une origine

proploc     localise un attribut ou toute autre propriété

notloc       localise des données arbitraires

bibloc       référence bibliographique à objet réel (externe)

nmquery     résultat d'une recherche par interrogation sous forme d'une liste de noms

mrkquery   interrogation par coordonnées

ilink         lien indépendant

clink         lien contextuel

fcs             espace fini de coordonnées

axis           définition d'axe

evsched     agenda d'événements

evgrp         groupe d'événements

event         événement

mallobj     objet malléable

accanch     liste d'ancrages ayant fait l'objet d'un accès

acctype     types d'éléments ayant fait l'objet d'un accès

acclink     élément lien ayant fait l'objet d'un accès

exrecon     stratégie de réconciliation

fcsloc       lieu dans un espace fini de coordonnées

calspec     spécification de calendrier

date           date

juldate     date du calendrier julien

abstime     temps absolu

timeoff     décalage horaire pour heure d'été ou fuseau

wandrule   règle portant sur la baguette magique

modrule     règle de modification

wand           baguette magique

modscope   champ de modification

wndpatch   patch de la baguette magique

modpatch   patch de modification

batrule     règle du bâton

baton         bâton (de chef d'orchestre)

proscope   champ du projecteur

projectr   projecteur d'événement

profun       fonction de projection

scaleref   référence d'échelle

rendrule   règle d'exécution

 

5.5.0.2 Formes architecturales de type liste d'attributs

 

Tous les éléments pré-cités ont une liste d'attributs correspondants.

 

Attributs supplémentaires (sans éléments correspondants):

 

overrun     débordement

exspec       spécification d'étendue

schdmeas   mesure d'agenda

function   fonction marqueur

docmdu       unité du domaine de mesure du document

locsrc       lieu origine

multloc     lieux multiples

spanloc     lieux définis sur zone

treecom     combinaison d'arbres

query         requête

sched         agenda

pls2gran   nombre de battements par granule

accend       accès à l'extrémité de lien

calendar   calendrier

 

 

5.5.0.3 Attributs communs

 

Certaines formes architecturales de listes d'attributs commencent par all-. C'est le cas de all-id, all-lex, all-ref, all-bits, all-dvl, all-desc, all-act et all-qual. On les appelle attributs communs parce qu'ils peuvent être appliqués à tous les types d'élément, HyTime et non-HyTime.

 

5.5.0.4 Liste des attributs communs

 

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 de traçage d'activité

all-qual   noms qualifiant les propriétés

 

5.5.0.5 Notations

 

sbento       attributs de la notation sbento de contenu informationnel

any-dcn     attributs utilisés dans dans sbento et dans nHyTime

 


[1]. SDIF est définie en ASN.1 (ISO 8824), ce qui assure la compatibilité avec les protocoles OSI (Open Systems Interconnection).

[2]. On utilise ici la syntaxe concrète de référence. Comme pour SGML, l'ensemble des symboles utilisés peut être modifié dans une application, à condition d'en préciser préalablement les règles. Voir Guide d'utilisation de SGML, p. 90.

[3]. Pour plus de détails sur la syntaxe des modèles de contenu, voir le Guide d'utilisation de SGML, p. 67 sqq.

[4]. Voir Norme ISO 8879:1986, SGML, appendice B, section B.5.1.1.

[5]. Pour l'explication complète de la signification de ces mots-clés, voir la norme ISO 8879:1986, SGML, claude 11.3.3. Voir également le Guide d'utilisation de SGML, p. 27 où les valeurs déclarées les plus fréquentes sont présentées.

[6]. Pour plus de détails, voir la clause 11.3.4 de la norme ISO/IEC 8879:1986 (SGML), ou le Guide d'utilisation de SGML, p. 27.

[7]. Le terme "data content notation" a été traduit dans la norme SGML par "notation de contenu textuel". Il est nécessaire de revoir ce terme dans le contexte de HyTime en traduisant "data" par "informationnel", car les notations sont utilisées notamment pour faciliter l'accès à des données multimédia (entrelacement, etc.).

[8]. Voir clause 11.4.1.2 de la norme SGML (ISO/IEC8879:1986, norme française NF EN 28879), p. 51 version française. Voir également Guide d'utilisation de SGML, p.76.

[9]. Cette clause a été élaborée afin de permettre à Apple de rendre compatible avec HyTime les notations utilisées dans le logiciel QuickTime, intégré dans le système 7.0 des ordinateurs Macintosh.