Vous êtes sur la page 1sur 19

SGML

par Luc SONKÉ

Docteur en mathématiques Président de STSI-SA (Société des Technologies et Systèmes d’Information), Paris

1.

Notions fondamentales

H 7 138 - 2

2

2

3

3

4

1.1

Origine de SGML

1.2

Quelques objectifs de SGML

1.3

Concept de documentation structurée

1.4

Balisage

1.5

Langages de balisage

— —

2.

Fondements conceptuels de SGML

4

2.1

Rappel de quelques catégories conceptuelles

4

2.2

Processus de modélisation

5

2.3

SGML est un métalangage

5

3.

Aspects formels de SGML

7

3.1

Notions de base

7

3.2

Codage des caractères

11

3.3

Notion de conformité

12

3.4

SGML et l’échange de documents

12

3.5

SGML sans DTD

12

3.6

Quelques grandes applications SGML

13

4.

Positionnement de SGML dans le contexte normatif

14

4.1

HyTime

14

4.2

SMDL

14

4.3

DSSSL

14

4.4

SPDL

14

5.

Évolutions dans les années à venir

— 14

5.1

Renforcement conceptuel

14

5.2

Vers des profils spécialisés

15

5.3

De nouvelles normes satellites

15

6.

SGML et l’ingénierie documentaire

15

6.1

Systèmes éditoriaux classiques

15

6.2

Ingénierie documentaire

— 15

6.3

SGML et l’ingénierie documentaire

17

6.4

Classification des outils SGML

17

7.

Conclusion

18

Pour en savoir plus

Doc. H 7 138

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 1

SGML

P aru en 1986, SGML (Standard Generalized Markup Language), métalangage de modélisation de documents structurés, suscite un grand intérêt dans des

univers professionnels aussi variés que l’édition, la recherche, l’industrie de l’armement et l’aéronautique. 1988 marque, au plan international, l’adoption de SGML comme standard d’échange de documents textes, par l’« Initiative » CALS (phase 1). En cette même année naît en France le projet SPEEDOC de la Marine nationale, premier projet de mise en œuvre d’une architecture documentaire articulée autour de documents SGML. Depuis, l’intérêt des utilisateurs et des spécialistes n’a fait que croître, pour une norme relativement compliquée. Le coût de l’acquisition et de la mise à jour de la documentation, son exploitation optimale, les problèmes liés aux échanges de documents et à la récupération intelligente de documents existants sont des raisons parmi d’autres de cet essor.

SGML permet en effet la mise en œuvre intelligente et efficace du concept de documentation structurée, à la base de toute approche rationnelle des problè- mes documentaires. SGML généralise le principe de balisage logique générique, en une méthodologie de génération de langages de balisage, et donne à l’utili- sateur des outils conceptuels pour construire des langages de balisage adaptés à ses propres applications. Notion centrale de ces langages, la Définition du Type de Document (DTD) est la grammaire formelle permettant de représenter les documents, en principe indépendamment de tout traitement qui pourrait leur être appliqué, ainsi que des moyens utilisés pour ces traitements. Par-delà ses nombreuses applications pratiques, SGML est d’un grand intérêt intellectuel en tant que métalangage et à travers le caractère inclassable des grammaires qu’il permet de construire. Une révision de SGML est en cours, qui intégrera au corps de la norme un cer- tain nombre de concepts, très abstraits pour certains, issus des travaux menés dans le cadre de normes connexes, tels HyTime et DSSSL. Émergent dans le temps, poussées en particulier par les besoins en applications documentaires professionnelles suscités par le Web-Intranet, des demandes pour une simplifi- cation de la norme. Ces demandes sont à l’origine de langages dérivés tels que XML. Ces deux tendances opposées permettent d’envisager pour SGML dans les années à venir, un accroissement de son audience déjà large, allant de l’inter- naute au chercheur spécialiste de la modélisation.

Nota : le terme Initiative caractérise, dans l’échelle de l’administration américaine, un projet (américain) de la plus haute importance, généralement d’envergure internationale.

1. Notions fondamentales

1.1 Origine de SGML

SGML (Standard Generalized Markup Language) est né des tra- vaux de synthèse de deux langages conçus sur le concept de bali- sage logique : GML (Generalized Markup Language), développé chez IBM par C.F. Goldfarb et GENCODE développé pour GCA (Gra- phic Communication Association) par W. Tunnicliffe.

SGML a aussi beaucoup profité des recherches faites sur les docu- ments structurés, notamment dans les milieux académiques, et en particulier, de langages comme Scribe de Brian Reid.

SGML a officiellement été adopté comme norme ISO (Internatio- nal Organization for Standardization) en octobre 1986 sous la réfé- rence ISO 8879.

Le présent article aborde succinctement tous les aspects de SGML. Il garde cependant, comme tout texte explicatif d’une norme, un caractère plus ou moins exégétique, par rapport au texte de réfé- rence qui demeure la norme elle-même. Le lecteur peut également consulter sur le même sujet Goldfarb [1], Bryan [2], van Herwijnen [3] et l’ouvrage publié en France par la Délégation Générale pour l’Armement [4].

1.2 Quelques objectifs de SGML

Nous rappelons ci-après sans commentaire (pour ne pas alourdir l’exposé), quelques principaux objectifs de SGML tels qu’ils appa- raissent dans le texte de la norme. Cet extrait est choisi, en raison de son poids sur certains choix techniques de la norme.

SGML doit pouvoir modéliser tous types de documents.

H 7 138 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

Les documents SGML doivent pouvoir se prêter à tous les types d’exploitation possibles.

SGML doit garantir la pérennité et l’échangeabilité des docu- ments, notamment au travers de l’indépendance vis-à-vis des plates-formes matérielles et logicielles.

SGML doit être indépendant des jeux de caractères et des langues nationales.

SGML doit pouvoir être à la fois humainement et automatique- ment interprétable.

1.3 Concept de documentation structurée

Longtemps réduit à la vision structurelle du document, par oppo- sition à une autre vision qui serait du type « présentation », le concept de documentation structurée n’est pas simple à énoncer. La frontière entre structure et présentation n’est en effet pas étanche. Certaines structurations sont conçues en vue de présentations parti- culières, cependant que certaines restitutions (présentations) d’un document portent de grandes significations sémantiques et structu- relles.

Introduisons les définitions suivantes :

— nous entendons par « approche orientée-document », une démarche d’organisation du document en fonction de catégories et modes courants de restitution ; — de même, une « approche informative » est une démarche d’organisation du document portée par son contenu informatif, indépendamment des traitements applicables à ce contenu.

Un exemple de ces deux approches est donné dans le tableau 1.

Tableau 1 – Cas d’une documentation technique de maintenance

 

Organisation selon une approche orientée-document

 

Organisation selon une approche informative

 

Introduction

Introduction

 

chapitre 1

Maintenance préventive

 

section 1 (paragraphe 1 ,

,

Alimentation (circuit pri-

paragraphe n )

maire,

,

fusibles)

section i (paragraphe 1 , paragraphe k )

 

 

,

 

,

Cabine (tableaux alarmes, commandes)

 

chapitre p

Maintenance corrective

section 1 (paragraphe 1 ,

   
 

,

Généralité (paragraphe 1 ,

 

paragraphe m )

 

,

paragraphe k )

 

 

section j (paragraphe 1 , paragraphe l )

 

,

Moteur (rotors,

 

tuyères)

 

,

On peut à présent donner la définition suivante pour le concept de documentation structurée :

Démarche d’organisation des données au sein d’un docu- ment, mettant en œuvre une approche informative de préfé- rence à une approche documentaire.

La préférence signifie ici qu’il n’y a pas d’opposition systématique entre les deux approches, l’une pouvant compléter l’autre à l’occa- sion.

Ce concept est le résultat d’une succession de tentatives d’organi- sations structurelles du document, au moyen de différentes techni- ques de marquage encore appelées balisages.

1.4 Balisage

Le balisage consiste en l’insertion de marques au sein d’un docu- ment, ce marquage visant à permettre et à faciliter ultérieurement divers traitements sur le document. Du balisage physique au bali- sage logique générique, ce principe de marquage s’est affiné pro- gressivement au gré des progrès de l’informatique éditoriale. Cette évolution de la notion de balisage peut être vue à la fois comme un élargissement progressif du champ des traitements possibles sur un document marqué, et comme la capacité accrue de marquer les documents les plus singuliers.

On peut enfin concevoir le balisage (en particulier le balisage logi- que générique) comme une mise en œuvre du concept de documen- tation structurée.

1.4.1 Balisage physique

Le balisage physique, encore appelé balisage procédural, est né avec les premiers formateurs intégrés aux grands systèmes (main- frame) des années soixante-dix. Il consiste à insérer dans le docu- ment des balises propres au système. Destinées au formateur auquel elles indiquent toutes les fonctions à exécuter pour présenter le document, ces balises ne font pas partie du contenu informatif du document. Elles ne sont pas nécessairement visibles par l’utilisa- teur, ainsi que le montre l’exemple ci-après d’un balisage RTF (Rich Text Format) de Microsoft.

Exemple : considérons la saisie sous un éditeur Word du texte sui- vant. Ceci est un exemple destiné à illustrer le concept de balisage physi- que. Les données RTF générées se présentent sous la forme du balisage

suivant :

20 Ceci est un exemple destin\’e 9\’e 0 {\b illus-

trer} le concept de {\i balisage physique}.\par }}

{{

\lsl\adjustright\fs

Dans cet exemple, outre le codage des caractères non ASCII,

on note les séquences {\b illustrer} et {\i balisage physique}, qui sont des exemples typiques de balisage physiques, c’est-à-dire de marquages destinés à donner au logiciel des instructions de

choix de fonte. On trouve aussi des instructions de présentation comme\adjustright, mais on ne voit que difficilement les instruc-

tions permettant de dire qu’il s’agit d’une liste énumérée.

Les formateurs ont rapidement proposé des systèmes de balisage avec un nombre réduit de balises sous forme de macrocommandes.

Cette évolution ne change pas le caractère procédural de tels balisa-

ges. Le contenu du concept évolue sensiblement avec le balisage logique.

1.4.2 Balisage logique

Le balisage logique peut être défini comme un mode de représen- tation des documents par marquage, qui consiste à décrire les composants des documents et les relations liant ces composants, indépendamment de la forme physique de présentation et des sup- ports de restitution de ces documents.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 3

SGML

Cette description mêle, pour un document donné, les données de contenu dudit document avec les balises repérant sa structure logi- que spécifique. Ici une structure est dite logique en ce sens qu’elle est a priori indépendante des traitements de présentation que l’on peut opérer sur le document.

Exemple : reprenant l’exemple donnée au paragraphe 1.4.1 et en s’inspirant de la syntaxe du langage LATEX, on peut imaginer le bali- sage suivant :

\begin {enumerate}

Ceci est un exemple destiné à \gras {illustrer} le concept de\concept {balisage physique}. \item \end {enumerate}

mais où les commandes

de présentation de Word sont remplacées par des commandes de

où l’on retrouve le choix des fontes (\gras

)

structuration (enumerate, item).

Utilisant la même syntaxe, la séquence \concept {balisage physi- que} introduit une conception du balisage non nécessairement orientée par la mise en forme physique du contenu balisé. Ici, l’expression « balisage physique » est repérée en tant que concept. Elle peut non seulement être présentée de multiples manières selon les supports de restitution (par exemple en italique, soulignée ou en gras sur le papier, en vidéo inverse ou clignotant à l’écran), mais aussi indexée pour pouvoir être recherchée en tant que concept.

1.4.3 Balisage logique générique

Un pas supplémentaire est franchi dans la généralisation du concept de balisage, avec l’apparition du balisage logique généri- que.

Un système de balisage logique générique se définit comme un balisage logique, étendu à une classe de documents. Les caractéris- tiques structurelles particulières d’un ensemble de documents sont décrites par un ensemble unique de balises génériques.

1.5 Langages de balisage

Un langage de balisage est une expression formelle du concept de balisage. Dans le cas du balisage physique, on parlera plus d’un ensemble de commandes destinées à un formateur que d’un lan- gage au sens formel.

Avec le balisage logique apparaissent les langages de balisage logique. Citons par exemple GML et LATEX déjà évoqués.

La notion de classe de documents existe en LATEX, c’est-à-dire que cette grammaire définit des variantes (en nombre limité) de balisages logiques permettant de décrire des ensembles particuliers de documents.

Nous verrons au paragraphe 2.3 que SGML se situe au-delà de la notion de langage de balisage. Il s’agit en fait d’un générateur de langages.

2. Fondements conceptuels de SGML

Ce paragraphe s’attache à montrer en quoi SGML peut être consi- déré comme un métalangage. L’exposé propose au lecteur des bases conceptuelles utiles pour une bonne compréhension théori- que de SGML.

2.1 Rappel de quelques catégories conceptuelles

On rappelle ici les trois principales catégories conceptuelles liées à la définition et à l’usage d’un modèle au sens informatique.

2.1.1 Modèle

Un modèle est la description d’un univers donné, en vue de sa prise en compte automatique. Par prise en compte automatique, on entend ici la génération ou l’interprétation, sur ordinateur, de don- nées appartenant à cet univers.

Le modèle peut, dans une phase initiale et éventuellement plu- sieurs phases intermédiaires, être spécifié au moyen de langages graphiques tels que NIAM (Nijssen Information Analysis Method) ou IDEF0 (Integrated computer-aided manufacturing DEFinition lan- guage - Functional Modeling). Cependant, ayant en vue la prise en compte automatique des modèles (à la différence des modèles mathématiques, par exemple), on est orienté vers la définition de modèles formels dont l’écriture en permet le traitement en machine. Des exemples de ces modèles (en restant dans le domaine docu- mentaire) sont RTF, LATEX ou HTML [5].

Cette remarque conduit également à inclure, dans la définition d’un modèle, les critères de conformité des futures instances du modèle.

2.1.2 Instance

Une instance est un assemblage cohérent de données valide dans un univers donné, c’est-à-dire conforme à un modèle donné. Elle est dérivée du modèle par valuation des différents paramètres et struc- tures prévus au sein de celui-ci. Il s’agit d’une donnée passive, en ce sens que, bien que valués, les paramètres qu’elle contient ne sont pas activés. L’instance peut être générée automatiquement ou non.

Le modèle définit une classe dont l’instance est un représentant. Le nombre d’instances n’est donc a priori pas limité.

La conformité de l’instance au modèle doit se vérifier par une pro- cédure automatique. On parle alors de parsing indépendamment de tout traitement possible sur cette instance. De ce point de vue, dans le domaine documentaire, la visualisation d’une instance composée ne peut suffire pour prononcer la conformité de cette instance à son modèle.

2.1.3 Occurrence

La notion d’occurrence désigne le résultat d’une exécution parti- culière d’une instance. Définir la génération d’une occurrence comme une exécution d’une instance revient à dire qu’une occur- rence n’est pas uniquement une transformation (réorganisation structurelle, par exemple) d’une instance donnée. Par-delà les éven- tuelles transformations, le processus de génération d’une occur- rence peut se caractériser de la manière suivante :

les paramètres du modèle valués à l’instanciation sont, cette fois, activés pour produire un résultat attendu, humainement interpréta- ble.

Dans le domaine documentaire, la génération d’une occurrence peut donc s’apparenter à l’application de styles de présentation.

Ainsi, l’occurrence se positionne vis-à-vis de l’instance comme l’instance elle-même se positionne vis-à-vis du modèle. L’occur- rence est en quelque sorte une instance (du modèle) au second ordre. Il s’agit cependant de la phase terminale du processus d’ins- tanciation. D’une occurrence, en effet, on ne peut dériver qu’une autre occurrence.

H 7 138 4

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

Le nombre d’occurrences que l’on peut générer à partir d’une ins- tance donnée est illimité.

S’agissant des occurrences, la notion de conformité est moins simple que dans le cas des instances. Il s’agit d’une conformité indi- recte, car la notion est ici attachée non aux occurrences elles- mêmes, mais aux outils (logiciels) produisant ces occurrences. La « conformité » des occurrences est indirectement garantie par la certification des outils qui les génèrent. Un exemple de certification en France est l’attribution de la marque NF de l’AFNOR.

2.2 Processus de modélisation

Ce paragraphe présente brièvement le processus de modélisa- tion.

Dans une approche simplificatrice, deux étapes peuvent être envi- sagées au sein du processus de modélisation : la structuration conceptuelle et l’approche formelle.

2.2.1 Structuration conceptuelle

Cette étape consiste en la définition de l’architecture du modèle. Elle inclut donc le recueil exhaustif des concepts caractérisant les situations à modéliser, l’articulation de ces concepts entre eux, etc. Ce travail relève essentiellement des compétences des acteurs du domaine d’activité que l’on se propose de modéliser. S’agissant du domaine de l’ingénierie documentaire, cette tâche sera prise en charge par des éditeurs, des documentalistes ou des spécialistes de la documentation technique, par exemple. Il peuvent être assistés dans la mise en perspective (au moyen de langages graphiques, par exemple) de ce travail par des spécialistes.

2.2.2 Approche formelle

Cette étape consiste à produire ce qui est habituellement appelé format ou modèle neutre. Il s’agit de la description détaillée de l’architecture issue de l’étape précédente, au moyen de langages formels traitables en machine. Selon la nature des situations à modéliser, une approche spatio-temporelle peut être adoptée, où le paramètre temps est explicitement repéré, avant toute gestion des chronologies et synchronisations généralement traitées à l’occur- rence.

Rappelons que la « neutralité » du modèle signifie qu’il est le résultat d’un consensus et est, de ce fait, susceptible de compréhen- sion et d’usage par le plus grand nombre.

La tendance habituelle consiste, dans un domaine donné, à définir un modèle formel dont l’ensemble des primitives prend en compte tous les concepts du domaine en question. Telle est par exemple l’approche suivie par la norme CGM [cf. Doc H 7 138], pour la modé- lisation des objets graphiques vectoriels en deux dimensions. On atteint rapidement les limites d’une telle approche, dès lors que l’univers à décrire n’est pas relativement simple. Et même dans des cas assez simples, l’introduction de nouveaux concepts entraîne la définition de nouvelles primitives dans le modèle, et donc l’amende- ment de celui-ci.

Lorsque les situations à modéliser sont de grande complexité (par exemple, les situations dont la description exhaustive conduit à envisager un nombre de cas conduisant vers une explosion combi- natoire), l’usage de métalangages s’avère indispensable. Cela signi- fie que les langages de modélisation utilisés sont en fait des grammaires générées par les utilisateurs (ou leurs mandataires qui en ont la compétence), à partir de ressources conceptuelles plus générales. Il s’agit alors de grammaires complètement conçues pour prendre en compte leurs situations spécifiques. Dans le

domaine de l’ingénierie documentaire, l’approche SGML relève de cette démarche.

Ainsi, une DTD (Définition du Type de Document) est une gram- maire particulière permettant la description d’une classe particulière de documents.

L’élément fédérateur de la norme est, dans ce cas, constitué de l’ensemble des ressources normalisées permettant aux utilisateurs de générer leurs grammaires. Les ressources incluent, outre les défi- nitions de jeux de caractères, séparateurs et syntaxes, les règles de définition des grammaires. La donnée des ressources et des gram- maires particulières constituent les modèles des différents utilisa- teurs.

Dans le cas de la norme SGML, les ressources sont indiquées dans une partie appelée SGML declaration (que nous appellerons par la suite déclaration SGML). Un modèle SGML est donc la don- née d’une déclaration SGML et d’une DTD (en fait un prolog). Nous reviendrons sur l’aspect métalangage SGML au paragraphe 2.3.

Pour être entièrement conforme à la démarche ISO, le processus de modélisation est complet lorsque le modèle (langage ou méta- langage) défini est accompagné des éléments nécessaires à la vali- dation automatique des instances qui seront produites et à la certification (au sens où nous l’avons envisagé au paragraphe 2.1.3) des pré et postprocesseurs du modèle.

Nota :

— un préprocesseur est un logiciel susceptible d’instancier (générer des instances) le modèle ;

— un postprocesseur est un logiciel susceptible d’interpréter les instances du modèle,

c’est-à-dire de les traiter, au sens large (par exemple, pour les modifier ou produire des

occurrences).

2.3 SGML est un métalangage

2.3.1 Introduction : approche intuitive

Considérons l’exemple donné aux paragraphes 1.4.1 et 1.4.2, comme fragment du document global, c’est-à-dire un article consa- cré à SGML. Une traduction SGML de ce fragment donne :

<article>

<titre>SGML</titre>

<p>Ceci est un exemple destiné à <gras>illustrer</gras> le concept de <concept>balisage physique</concept></p>.

</article>

Ce balisage fait apparaître le fragment considéré comme un paragraphe (ce que signifie les balises <p> et </p>) au sein d’un document de type article (ce que signifie les balises <arti- cle> et </article>), donc le titre est SGML (ce que signifie les balises <titre> et </titre>).

Au sein du fragment, l’expression « balisage physique » est repé- rée comme concept par les balises <concept> et </concept>. Un logi- ciel sachant interpréter le balisage défini pourra opérer la mise en gras du mot « illustrer », dès lors qu’il détectera les balises <gras> et </gras>.

Ces explications supposent que soit défini quelque part un ensemble de conventions donnant notamment :

— la liste et la syntaxe des balises définies pour marquer le document ;

— l’articulation des balises au sein du document ;

— les règles particulières d’utilisation des balises.

Ces règles sont rassemblées au sein de ce qui constitue le modèle du document, la DTD. Ce concept SGML de DTD sera précisément défini au paragraphe 2.3.3.2, puis développé au paragraphe 3.1.2.1.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 5

SGML

Le balisage utilisé dans l’exemple qui précède est donc défini par une DTD. Un aspect au moins de cette DTD est très rudimentaire. Il s’agit de la définition des balises <gras> et </gras>, conçues pour indiquer, à un logiciel de présentation, la mise en gras d’une partie du texte. Inspirée de la présentation initiale du texte à baliser, la défi- nition de cette balise ne couvre cependant pas d’autres traitements qui, bien que différents de la mise en gras, relèvent cependant de la même notion.

On peut ainsi définir une nouvelle DTD permettant, à travers une même balise, d’indiquer, selon les logiciels et support de restitution, les traitements tels que la mise en gras, la mise en italique, le souli- gnement, la mise en vidéo inverse ou la mise en clignotant. Ces trai- tements relèvent en effet tous de la notion de « mise en évidence ».

Une nouvelle version SGML du fragment présenté plus haut se présente comme suit :

<article>

<titre>SGML</titre>

<p> Ceci est un exemple destiné à <mise-en-evidence type=”gras”> illustrer </mise-en-evidence> le concept de <concept> balisage physique </concept> </p>.

</article>

Dans ce nouvel exemple, la balise <gras> est remplacée par la balise <mise-en-evidence type=”gras”>. Cette nouvelle balise per- met d’indiquer le type de mise en évidence souhaité, en affectant une valeur à l’attribut « type » (ici, la valeur est « gras ». Mais elle pourrait être « italique », « clignotant », etc.). La notion d’attribut sera définie au paragraphe 3.1.2.1.3.

En conclusion à cette brève introduction, il apparaît que :

— SGML permet de définir un modèle de document (DTD) per-

mettant le balisage d’une classe de documents ;

— un même document peut recevoir plusieurs modèles de docu- ment au sens SGML.

Après ces exemples, nous allons à présent entrer plus en détail dans les ressorts SGML comme métalangage.

2.3.2 Du balisage logique à la génération de langages de balisage

Comme rappelé au paragraphe 1.4.2, le balisage logique d’un document est le processus consistant à repérer, au moyen d’une série de marques prédéfinies, les composantes de ce document et à décrire les relations liant ces composantes, indépendamment de la forme physique de restitution de ce document pour exploitation humaine. Cette description mêle les données de contenu et les don- nées repérant la structure du document.

L’ensemble de ces marques prédéfinies (ou encore balises) constitue un langage de balisage. Quelques exemples de langage de balisage ont été présentés au paragraphe 1.5. Chacun de ces langa- ges est doté d’une syntaxe et d’un système propres de désignation des balises.

Il peut cependant arriver que deux de ces langages soient équiva- lents, en ce sens qu’ils sont conçus pour représenter une même classe de documents. Chaque langage n’est alors qu’une vue struc- turelle particulière de la même classe de documents. Dans ces conditions, imposer un langage de balisage à un utilisateur apparaît comme une démarche arbitraire.

D’où l’idée maîtresse des concepteurs de SGML :

Donner aux utilisateurs des outils conceptuels leur permettant de créer par eux-mêmes des langages de balisage adaptés à leurs applications.

SGML généralise le principe de balisage logique en l’étendant en un concept plus général : la GÉNÉRATION de LANGAGES de BALI- SAGE. En cela, SGML est un métalangage.

2.3.3 Document au sens SGML

En tant que métalangage, SGML peut être conçu comme un ensemble générique de règles permettant de construire des langa- ges de balisage logique. Ces langages de balisage sont des modè- les, au sens des catégories conceptuelles rappelées au début du paragraphe 2. Selon ces catégories, SGML introduit donc un niveau conceptuel supplémentaire, en deçà du niveau modèle, le niveau métamodèle.

Un document au sens SGML est la donnée, au sein d’un même document logique, des trois composantes :

— la déclaration SGML (métamodèle) ;

— le

(modèle),

prolog

que

nous

appellerons

prologue ;

— l’instance.

2.3.3.1 Déclaration SGML

par

la

suite

La déclaration SGML représente le niveau métamodèle. C’est l’ensemble des ressources permettant aux utilisateurs de générer leurs propres modèles, c’est-à-dire les types de document. En théo- rie, la déclaration SGML permet de définir tout dans le modèle.

Ainsi, par exemple, elle ne fige pas la syntaxe (les délimiteurs, les mots-clés, les symboles spéciaux, etc.) d’écriture des types de docu- ments. À travers la déclaration par défaut de la norme et sa syntaxe concrète de référence, SGML offre les règles de construction des syntaxes concrètes particulières.

Dans la pratique, selon le domaine d’application, on fixera une syntaxe concrète et l’on choisira parmi les fonctionnalités propo- sées par la déclaration SGML celles dont on a besoin. Définir ainsi un modèle revient à bâtir une application de SGML.

2.3.3.2 Prologue

Au sens des catégories conceptuelles rappelées au paragraphe 2, le prologue se positionne au niveau modèle. Il rassemble les décla- rations du type de document (DTD) et les déclarations de type de lien (LPD - Link Process Declaration).

De SGML, beaucoup d’utilisateurs ne retiennent que cette partie prologue, plus particulièrement la DTD. C’est qu’implicitement ils se limitent aux ressources que propose la déclaration SGML par défaut, ce qui pose parfois des problèmes, lorsque, par exemple, la syntaxe concrète de référence ne suffit pas pour prendre en compte toutes les particularités d’une classe de documents donnée.

2.3.3.3 Instance

L’instance est le contenu informatif du document, marqué par les balises qui le structurent. Il s’agit de la partie du document qui est la plus accessible à l’utilisateur, mais qui demeure incompréhensible en l’absence de la DTD.

2.3.4 Par-delà la génération de grammaires

Nous concluons cette partie, consacrée aux ressorts conceptuels de la norme, par une discussion au sujet de la nature des grammai- res que permet de générer SGML.

H 7 138 6

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

 

Tableau 2 – Syntaxe concrète de référence

Rubrique

Syntaxe

Signification

Syntaxe concrète

abstraite

de référence

 

STAGO

Ouverture d’une balise de début

<

Balisage

ETAGO

Ouverture d’une balise de fin

</

TAGC

Fermeture d’une balise (début ou fin)

>

 

MDO

Ouverture d’une déclaration

<!

MDC

Fermeture d’une déclaration

>

PIO

Ouverture d’une instruction de traitement

<?

Déclarations et appels d’entités

PIC

Fermeture d’une instruction de traitement

>

ERO

Ouverture d’un appel d’entité externe

&

 

PERO

Ouverture d’un appel d’entité paramètre

%

CRO

Ouverture d’un appel d’entité caractère

&#

REFC

Fermeture d’un appel d’entité

;

 

Groupage

GRPO

Ouverture d’un groupe

(

GRPC

Fermeture d’un groupe

)

 

OPT

Occurrence optionnelle (0 ou 1 occurrence)

?

Indicateur

PLUS

Occurrence obligatoire multiple (1 occurrence et plus)

 

d’occurrence

+

Modèle

REP

Occurrence optionnelle multiple (0 occurrence et plus)

*

de contenu

 

SEQ

Séquence (occurrence des éléments dans l’ordre)

,

Connecteur

OR

Choix (occurrence d’un seul élément à la fois)

|

AND

Occurrence des éléments dans un ordre quelconque

&

Autre

RNI

Indicateur de nom réservé

#

 

VI

Indicateur de valeur d’un attribut

=

Attributs

LIT

Délimiteur de la valeur littérale d’un attribut

’’

LTA

Autre délimiteur de la valeur littérale d’un attribut

Les expressions régulières sont utilisées dans la norme SGML pour exprimer les règles de production (plus de 200) qui constituent la spécification de référence, mais également pour l’expression des déclarations des modèles de contenu dans une DTD. Cependant, la présence de constructions récursives montre que les modèles de balisage produits par SGML ne relèvent pas de la catégorie des lan- gages contextuels. On sait ainsi que les algorithmes basés sur la théorie des automates finis sont insuffisants pour analyser des documents SGML.

Beaucoup de règles SGML permettant des simplications d’écri- ture sont exprimables à l’aide de la notation BNF. Il s’agit par exem- ple des règles de minimisation, des règles d’expression des exceptions (inclusions et exclusions). Les langages SGML ne relè- vent pas pour autant de la catégorie des grammaires non contex- tuelles. Certaines règles de la norme, telles que la règle de non- ambiguïté des modèles de contenu, ne sont en effet pas exprima- bles par une grammaire.

Si l’on ajoute aux observations qui précèdent le fait que SGML définit (à travers les appels abrégés et la gestion des liens, par exemple) des traitements applicables aux diverses parties des docu- ments (DTD et instances) lors de leur analyse, on mesure la portée de cette norme qui est bien plus importante qu’un générateur de langages formels. On mesure du même coup la complexité des outils d’analyse des documents au sens SGML.

3. Aspects formels de SGML

3.1 Notions de base

Ce paragraphe expose les concepts de base de la norme SGML, dans leurs aspects formels. Il ne s’agit pas ici de définitions formel- les telles qu’elles sont données dans la norme au moyen de règles de production. Nous abordons ces concepts à travers ce qui est déjà une première interprétation des règles de production, à savoir la syntaxe concrète de référence. Le tableau 2 rappelle la syntaxe concrète de référence. Ce tableau illustre au passage (par la syntaxe) le caractère méta- langage de SGML, la syntaxe concrète de référence pouvant être remplacée par toute autre syntaxe concrète, du moment qu’elle interprète sans ambiguïté la syntaxe abstraite.

3.1.1 Déclaration SGML

Écrite uniquement à l’aide de la syntaxe concrète de référence, la déclaration SGML définit :

— le jeu de caractères utilisés dans le document ;

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 7

SGML

— la capacité mémoire nécessaire au traitement du document ;

— les champs d’utilisation de la syntaxe concrète ;

— la syntaxe concrète elle-même ;

— les fonctionnalités (choisies parmi celles proposées par la

norme) utilisées dans le document ;

— les informations concernant d’éventuelles applications spécifi-

ques.

Les six rubriques précédentes apparaissent dans la déclaration SGML sous six clauses identifiables dans l’ordre par les noms réservés : CHARSET, CAPACITY, SCOPE, SYNTAX, FEATURES et APPINFO.

Nous donnons sur la figure 1 un exemple de déclaration SGML.

3.1.2 Prologue

Comme nous l’avons vu au paragraphe 2.3.3.2, le prologue contient les déclarations des types de document (DTD), dont l’une est la déclaration du type de document de base, et les déclarations des types de liens (LPD). Ce paragraphe est consacré à la description formelle des concepts de base de ces composantes du prologue.

3.1.2.1 DTD

La DTD décrit, dans un langage spécifique (l’ensemble des mots réservés de SGML et la syntaxe concrète définie dans la déclaration SGML), la structure formelle du type de document que l’on se pro- pose de modéliser.

Historiquement, la DTD comporte les quatre catégories de décla- rations suivantes :

— les déclarations d’éléments ;

— les déclarations des listes d’attributs ;

— les déclarations d’entités ;

— les déclarations d’appels abrégés.

L’exposé ne traitera pas des appels abrégés, mécanismes assez complexes et d’une mise en œuvre délicate, que la norme a aban- donnés.

Est décrite ci-après, non pas au moyen de règles de production mais en utilisant la syntaxe concrète de référence, chacune de ces constructions. Les mots reservés et les symboles de la syntaxe concrète de référence sont indiqués en gras.

Toute déclaration ou définition s’ouvre par le symbole <!(MDO) et s’achève par le symbole >(MDC) :

<! contenu_d’une_déclaration >

3.1.2.1.1 Le type de document

La forme générale de déclaration d’une DTD est la suivante :

<!DOCTYPE

nom_du_type_de_document

identificateur_externe

[déclarations]>

où :

— DOCTYPE est le mot réservé qui annonce la déclaration d’un type de document ;

nom_du_type_de_document est l’identificateur du type de

document. Il ne peut apparaître comme identificateur d’un autre

type de lien, ni d’un autre type de document, au sein du même prologue ;

identificateur_externe pointe sur une entité référencée qui constitue, avec les déclarations, la déclaration du type de document ;

— entre les crochets [déclarations] sont déclarées les diverses

parties de la structure du document ainsi que les éventuelles abré-

viations adoptées. Nous détaillons ci-après quelques-unes de ces déclarations.

3.1.2.1.2 Les éléments

La forme la plus générale de déclaration des éléments est la suivante :

+

(e 1 , e 2 ,

avec :

— ELEMENT mot réservé qui annonce la déclaration d’un ou de plusieurs éléments ; et le modèle de contenu qui se décompose comme suit :

<!ELEMENT (elm 1 , elm 2 ,

,e

i ) – (ex 1 , ex 2 ,

,elm , ex n )>

k )

– O

(el 1 , el 2 ,

,el

–j )

• (elm 1 ,

, elm k ) est le groupe de modèle, composé des k

noms d’éléments que l’on définit (il n’y a pas de parenthèses lors- que k = 1) ;

• – O sont les indicateurs d’omission de balisage de début et de fin d’élément ;

) est le contenu commun aux éléments déclarés,

composé des j éléments el 1 ,

(el 1 ,

,

el –j

, el j ; et enfin les exceptions :

• (e 1 , e 2 ,

• (ex 1 , ex 2 ,

, e i ) groupe d’éléments inclus ;

, ex n ) groupe d’éléments exclus.

Inclusions et exclusions sont définies ci-après.

Exceptions

Inclusions :

–(ex 1 , ex 2 ,

,

ex n ) Exclusion des éléments ex 1 ,

, ex n . Leur occur-

rence est impossible dans chacun des éléments elm 1 ,

même si la définition des sous-éléments el 1 , présence.

, elm k

, el j autorise leur

Exclusions :

+(e 1 , e 2 ,

, e i . Leur occurrence

, elm k même si leur défini-

tion n’est pas explicite dans les sous-éléments el 1 ,

L’exclusion d’un élément rendu obligatoire par le groupe de modèle est interdit.

L’exclusion a la priorité sur l’inclusion. Autrement dit un élément à la fois autorisé par une inclusion et interdit par une exclusion est exclu à tous les niveaux hiérarchiquement inférieurs au niveau où a lieu la déclaration.

Ces deux règles montrent qu’il est préférable d’indiquer les exceptions au plus près des éléments concernés, c’est-à-dire le plus bas possible dans la structure hiérarchique.

Groupe de modèle

SGML utilise les connecteurs « , », « & » et « | » pour préciser le contenu d’un groupe de modèle. Le groupe de modèle décrit donc le contenu d’un élément au moyen d’une expression régulière composée d’identifiants d’éléments. Les éléments terminaux (don- nées textuelles) sont indiqués par le symbole #PCDATA.

, est autorisée dans les éléments elm 1 ,

e i ) Inclusion des éléments e 1 ,

, el j .

Groupe de modèle

Signification

(el 1 , el 2 ,

,

el j )

Les j éléments doivent obligatoirement être

 

présents dans les éléments décrits, et dans l’ordre qui est indiqué.

(el 1 & el 2 &

&el j )

Les j éléments doivent obligatoirement être présents, mais dans n’importe quel ordre.

(el 1 | el 2 |

|el j )

Un et un seul des j éléments doit être pré- sent dans les éléments décrits.

Les éléments el 1 , el 2 ,

,

el –j

peuvent éventuellement être suivis

, el

d’un symbole d’occurrence, par exemple (el 1 , el 2 *, el 3 ?, el 4 + ,

j ).

H 7 138 8

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

<!SGML "ISO 8879-1986" -- Default SGML declaration using the reference concrete syntax --

CHARSET BASESET "ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"

DESCSET 0

128

0

128

128

UNUSED

CAPACITY PUBLIC "ISO 8879-1986//CAPACITY Reference//EN" SCOPE DOCUMENT SYNTAX PUBLIC "ISO 8879-1986//CAPACITY Reference//EN" SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127 255 BASESET "ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"

DESCSET

0

128

0

FUNCTION

RE

13

RS

10

SPACE

32

TAB

SEPCHAR

9

NAMING

LCNMSTRT ""

UCNMSTRT ""

LCNMCHAR "-"

UCNMCHAR "-" NAMECASE GENERAL

YES

ENTITY

NO

DELIM

GENERAL SGMLREF

 

NAMES

SHORTREF SGMLREF SGMLREF

QUANTITYSGMLREF

 

FEATURES

MINIMIZE

DATATAG

YES

OMITTAG YES

RANK

YES

SHORTTAG

YES

LINK

SIMPLE

YES

10 IMPLICIT

YES

EXPLICIT

YES

10

OTHER

CONCUR

YES

10 SUBDOC

YES

10

FORMAL

NO

APPINFO NONE>

Figure 1 – Exemple de déclaration SGML

Symbole

Signification

 

Élément obligatoire, éventuellement répéti-

+

tif (1 ou plus)

?

Élément optionnel qui ne peut être répétitif

(0 ou 1)

*

Élément optionnel, éventuellement répétitif

(0 ou plus)

Éléments à contenu déclaré Le contenu d’un élément à contenu déclaré peut prendre l’une des valeurs suivantes : CDATA, RCDATA, EMPTY, où :

— CDATA (Character Data) indique que toutes les chaînes de caractères constituant le contenu de l’élément déclaré, y compris les

chaînes de caractères interprétées comme des balises ou des appels d’entités, sont à considérer (par un parseur) comme des données textuelles ;

— RCDATA (Replaceable Character Data) se distingue du contenu

CDATA par le fait que les appels d’entité sont ici pris en compte ;

— EMPTY indique un contenu vide.

Pour les éléments à contenu déclaré CDATA ou RCDATA, l’option de minimisation de balisage est nécessairement « -- ». Autrement dit, la présence des balises de début et de fin de ces éléments est obligatoire.

La balise de fin est en revanche omise pour les éléments à contenu déclaré EMPTY.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 9

SGML

Non-ambiguïté des modèles de contenu

Il s’agit d’une clause non exprimable par une grammaire formelle. L’énoncé de la règle est le suivant :

À toute occurrence d’un élément dans le document instance, le parseur doit pouvoir déterminer son groupe de modèle d’appartenance, sans lecture anticipée. L’exemple ci-après est extrait du texte de la norme.

Le modèle de contenu suivant :

<!ELEMENT e

((a,b?), b)>

est ambigu, car après l’occurrence du « a », on ne peut déterminer absolument le groupe d’appartenance de « b ». L’ambiguïté peut être levée par une déclaration intermédiaire, ainsi qu’il suit :

<!ELEMENT e

(f, b)>

<!ELEMENT f

(a,b?)>

3.1.2.1.3 Les attributs

La forme courante de définition d’attribut est la suivante :

<!ATTLIST elem attribut1

type1

valeur_par_défaut1

attribut2

type2

valeur_par_défaut2

attribut_n

type_n

valeur_par_défaut_n >

où :

— ATTLIST est le mot réservé qui annonce la déclaration d’une liste d’attributs ;

elem est le nom de l’élément dont on définit les attributs ;

attribut_k est le nom du k e attribut déclaré ;

type_k est un mot-clé qui précise la nature du contenu du k e attribut.

On a :

Mot-clé

Nature du contenu de l’attribut

NUMBER(S)

Nombre ou liste de nombres

NUTOKEN

Chaîne de caractères commençant néces- sairement par un chiffre

NMTOKEN

Chaîne de caractères ne commençant pas nécessairement par une lettre

ENTITY(IES)

Un nom (ou des noms) d’entité(s) géné- rale(s)

CDATA

Une chaîne de caractères quelconque

ID

Identificateur (un nom SGML) d’un élément

NAME(S)

Un nom SGML

En outre, valeur_par_défaut_k est une des valeurs autorisées (entre quotes) pour le k e attribut, ou un des mots-clés suivants :

Mot-clé

Signification

#REQUIRED

La valeur de l’attribut doit obligatoirement être indiquée

#IMPLIED

Le système définira une valeur pour l’attri- but si aucune valeur n’est indiquée

#FIXED

L’attribut a une valeur fixe qui est unique

#CURRENT

La dernière valeur indiquée sera utilisée par défaut si aucune valeur n’est spécifiée

3.1.2.1.4 Les entités

Certaines données ou ensembles de caractères peuvent être des- tinés à s’insérer dans le document (des données issues d’autres sources, par exemple), sans qu’il soit nécessaire de les saisir direc- tement. Ces ensembles sont alors référencés sous des noms symbo- liques. Ce sont les entités.

Les entités SGML peuvent se classer en trois catégories : les enti- tés générales, les entités paramètres et les entités externes.

Les entités générales

Référencées dans une DTD ou un LPD, elles sont destinées à être utilisées dans le document instance. La forme de leur déclaration est la suivante :

<!ENTITY nom_de_l’entité

contenu_référencé>

où :

— ENTITY est le mot réservé qui annonce la déclaration d’une entité ;

nom_de_l’entité est le nom de l’entité déclarée ;

contenu_référencé est le contenu de l’entité déclarée, avec

pour valeur possible : un paramètre littéral, du texte entre crochets,

des données textuelles, une spécification d’entité externe.

À l’intérieur du document, l’insertion du contenu référencé sera indiquée par un appel d’identité dont la syntaxe est donnée par &nom_de_l’entité ;

Exemple : on peut saisir &ISO ; dans le courant du document, au lieu de International Organization for Standardization. Dans la DTD, on aura alors la déclaration suivante :

<!ENTITY ISO “International Organization for Standardization”>

Les entités paramètres

Elles sont utilisées, dans les déclarations de balisage, pour regrouper des noms d’éléments jouant des rôles analogues. La déclaration et l’appel d’entité paramètre ont des syntaxes différen- tes de celles des entités générales.

<!ENTITY % nom_de_l’entité

où :

contenu_référencé”>

nom_de_l’entité est le nom de l’entité déclarée ;

contenu-référencé est le contenu de l’entité déclarée, du texte

entre crochets.

Dans la DTD, l’appel se fera par % nom_de_l’entité.

Les entités externes

Il s’agit d’entités paramètres ou générales, mais dont le contenu référencé est externe. contenu_référencé est alors la référence (par exemple, un nom de fichier) au texte de l’entité qui est stocké par ailleurs. Les entités externes ont l’une des formes de déclaration sui- vantes.

Entité système :

<!ENTITYnom_de_l’entité SYSTEM identificateur_système>

où :

SYSTEM est le mot réservé qui caractérise une entité système ;

identificateur_système indique au système la valeur de l’entité déclarée.

Entité public :

<!ENTITY % nom_de_l’entité PUBLIC identificateur_public identificateur_système>

où :

— PUBLIC est le mot réservé qui caractérise une entité publique ;

identificateur–public indique l’identité de l’entité déclarée, qui est indépendant du système ;

identificateur_système indique la manière dont le système accède localement à l’entité déclarée.

H 7 138 10

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

L’entité public est nécessairement formel lorsque l’option FORMAL est activée dans la déclaration SGML. La déclaration est typée par l’un des mots-clés du tableau suivant.

Mot-clé

Signification

SUBDOC

L’entité contient un sous-document

CDATA

L’entité contient des données textuelles

SDATA

L’entité contient des données spécifiques au système

NDATA

L’entité contient des données qui ne sont pas des données SGML

Notation :

Elle permet d’appeler des données externes qui ne contiennent pas du texte SGML. Deux formes de déclaration sont possibles :

<!NOTATION nom_de_notation SYSTEM identificateur_système>

<!NOTATION nom_de_notation PUBLIC identificateur_public identificateur_système>

3.1.2.1.5 Les commentaires

Au sein d’une déclaration, tout texte encadré par deux doubles tirets « -- » est considéré comme un commentaire ; par exemple :

<!-- ceci est un commentaire -->

SGML permet le contrôle de la structure et de la syntaxe des élé- ments déclarés, mais pas leur sémantique. L’usage efficace des commentaires peut aider à appréhender la sémantique des élé- ments et autres contraintes qui leur sont attachées.

Les commentaires sont d’une grande utilité pour fournir informa- tions et contraintes non exprimables par le langage seul, notam- ment :

— des informations au sujet des éléments (sémantique, conseil d’utilisation, etc.) ;

— des informations au sujet de l’objectif, de la structure et du sta- tut (version, mise à jour, etc.) de la DTD ;

— des informations au sujet de la signification des attributs ;

— des informations au sujet des outils spécifiques permettant l’organisation et la mise en œuvre de l’application.

Les commentaires peuvent éventuellement être exprimés au moyen de langages formels adaptés (par exemple, un langage de contrôle qui précise le contenu sémantique d’un élément déclaré – on parle alors de contenu typé). Des parseurs évolués peuvent alors prolonger l’analyse structurelle et syntaxique des documents par l’analyse sémantique de leur contenu. De tels parseurs existent dans le commerce, généralement basés sur des grammaires d’expressions régulières.

3.1.2.1.6 Les références croisées ID IDREF

Ce mécanisme permet d’attacher à un élément (comme attribut) de la DTD un identificateur unique ID. L’élément peut ainsi être par- tout référencé par un autre élément, lui-même muni d’un autre iden- tificateur IDREF.

Exemple d’un fragment de déclaration utilisant le mécanisme ID- IDREF :

<!ELEMENT ref - O EMPTY -- élément utilisé pour acquérir une référence interne -->

<!ATTLIST ref ref

IDREF #REQUIRED -- nom de l’élément référencé -->

<!ELEMENT livre

- O (aa, bb, cc) -- structure livre

-->

<!ATTLIST livre nom ID

#IMPLIED>

ID et IDREF sont bijectivement associés l’un à l’autre. Dans une instance cependant, la relation ID IDREF est multivoque, c’est-à-

dire que plusieurs occurrences de la balise portant l’attribut IDREF sont possibles au sein du même document instance.

3.1.2.1.7 Les sections marquées

Il s’agit d’une fonctionnalité de base de la norme, même si cer- tains systèmes ne les traitent pas tous. Elles déclarent certaines par- ties du document destinées à recevoir des traitements particuliers.

La forme de la déclaration est la suivante :

<![type_de_traitement [contenu_à_traiter]]>

contenu_à_traiter est le texte de la section marquée et type_de_traitement peut prendre l’une des valeurs suivantes :

— IGNORE : contenu_à_traiter est ignoré ;

— INCLUDE : contenu_à_traiter est inclus ;

— RCDATA :

dans

contenu_à_traiter ;

— CDATA : les caractères spéciaux SGML de contenu_à_traiter sont ignorés ;

seuls

les

appels

d’entités

sont

traités

— TEMP : contenu_à_traiter est inclus, mais temporaire.

3.1.2.2 LPD

Les définitions de processus de liens (LPD - Link Process Definition) ne sont évoquées ici qu’à titre historique, les objectifs visés par ces constructions étant désormais repris intégralement par la norme DSSSL (cf. [Doc H 7 138]).

Les LPD ont en effet été conçus au départ pour associer, à un type de document donné (DTD), un autre type de document, dans un but de formatage. Il s’agit d’une transformation du type document logique document physique.

Concrètement, le LPD regroupe au sein du prologue un ensemble de déclarations d’attributs. Ces attributs spécifiques sont associés (mis en correspondance) avec les éléments d’une DTD donnée, sans modification de cette dernière.

3.1.3 Instance

L’instance SGML correspond bien à la définition générale que nous avons donnée de la notion d’instance au paragraphe 2.1.2. Il s’agit du document balisé conformément à son modèle, la DTD.

Les divers éléments déclaré dans la DTD reçoivent ici leurs conte- nus sous forme de texte ou d’identifiant des adresses de leurs contenus ; les attributs sont valués, les liens sont résolus. L’instance peut contenir des sections marquées et des sous-documents.

L’instance est donc le document apte à recevoir (presque) tous les traitements de gestion et d’exploitation mis en place par les utilisa- teurs dans le cadre d’applications particulières ; par exemple :

— la migration de composants du document vers une base de données de gestion de fragments ;

— l’échange de fragments ;

— la composition selon divers styles.

3.1.3.1 Instructions de traitement

Parce que liés à des systèmes particuliers, certains traitements effectués sur une instance peuvent exploiter, outre le balisage du document conformément à sa DTD, des instructions spécifiques insérées dans le corps du document. Il s’agit des Processing Instruc- tion (PI).

Les PI peuvent apparaître à n’importe quel endroit au sein du document. Leur syntaxe est la suivante :

<?instruction_de_traitement>

où :

— <? est la syntaxe concrète pour PIO (processing instruction open - ouverture d’une instruction de traitement) ;

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 11

SGML

instruction_de_traitement une instruction destinée au système de traitement du document.

Lors de l’analyse du document, le parseur ignore les PI, c’est-à- dire qu’il suspend l’analyse à partir de la détection du PIO (<?) et ne la reprend qu’après le PIC (fermeture d’une instruction de traite- ment, >).

3.1.3.2 Forme canonique

On appelle ainsi la forme d’une instance SGML validée telle qu’elle peut être récupérée à la sortie d’un parseur. Un tel docu- ment se caractérise par sa complétude et la présence systématique des balises volontairement omises à la saisie (lorsque la fonction OMITTAG est active). La complétude du document implique la résolution des liens, la substitution des valeurs d’entité à leurs appels dans les éléments à contenu déclarés RCDATA, le traitement des références aux sections marquées, etc.

3.2 Codage des caractères

L’un des objectifs explicitement visés par SGML est l’indépen- dance vis-à-vis des jeux de caractères. Ainsi, bien que la déclaration SGML par défaut soit basée sur le codage ISO 10646, la norme per- met de redéfinir le jeu de caractères, en fonction des besoins des applications que l’on souhaite bâtir.

Tout jeu de caractères permettant la représentation de lettres, de chiffres, de blanc insécable et autres délimiteurs, est candidat poten- tiel pour le codage de documents SGML.

Cette possibilité de redéfinir le jeu de caractères est manifeste- ment un avantage, lorsque l’on considère les possibilités très limi- tées du jeu de caractères de la déclaration SGML par défaut.

Elle pose cependant quelques problèmes pratiques lorsque les documents sont échangés, les systèmes de part et d’autre n’étant pas toujours en mesure d’interpréter les différents jeux de caractères. Cette difficulté devrait être surmontée prochaine- ment avec l’adoption par SGML du codage UNICODE (ISO 10646) (cf. [Doc H 7 138]).

3.3 Notion de conformité

Étant donné la complexité et les nombreuses fonctionnalités de SGML, il s’avère difficile de trouver des outils susceptibles de cou- vrir l’intégralité des possibilités de la norme. Conscients de cette dif- ficulté, les concepteurs de la norme ont défini pour les documents SGML plusieurs niveaux de conformité. La notion de document SGML est entendue au sens de la définition donnée au paragraphe

2.3.2.

Dans la pratique, la conformité d’un document SGML est établie, moyennant l’analyse de ses trois composantes (déclaration SGML, prologue, instance) par un parseur. En théorie, un tel parseur devrait être certifié, c’est-à-dire avoir subi avec succès un examen basé sur une suite de tests SGML, et avoir reçu un label SGML par un centre agréé.

SGML distingue historiquement la syntaxe concrète de référence entière autorisant l’emploi des appels abrégés dans les DTD tout en déterminant la liste des délimiteurs autorisés (comme abréviations), de la syntaxe concrète de référence minimale qui n’admet pas d’appels abrégés.

Sur la base de ces distinctions, nous pouvons donner les défini- tions ci-après.

Document SGML de base

Un document SGML de base est un document basé sur la syntaxe concrète de référence entière et les capacités de référence telles qu’indiquées dans la déclaration SGML, les seules fonctionnalités actives étant SHORTTAG et OMITTAG.

Document SGML minimal

Un document SGML minimal est un document basé sur la syntaxe concrète de référence minimale et les capacités de référence telles qu’indiquées dans la déclaration SGML, sans aucune fonctionnalité active.

Autres documents SGML

Il s’agit des documents SGML basés sur des variantes de syntaxe concrète.

3.4 SGML et l’échange de documents

Parmi les objectifs poursuivis par SGML, l’échange des docu- ments entre partenaires est l’un des plus importants. L’échange est ici entendu au sens de l’EDI (Electronic Data Interchange), c’est-à- dire d’ordinateur à ordinateur, voir d’application à application. Le but visé est la non-intervention manuelle dans la chaîne électroni- que de l’information.

SDIF (Standard Document Interchange Format) spécifie dans la norme ISO 9069 (cf. [Doc H 7 138]) le format d’échange de docu- ments SGML. Il spécifie l’empaquetage, au sein d’un flot unique de données, des divers parties (types de documents, entités externes, documents externes, etc.) d’un document SGML, au moyen de des- cripteurs indiquant les liens entre ces parties.

Entre autres données, SDIF permet la transmission entre systè- mes :

— du jeu de caractères utilisé ;

— des instructions de traitement (délimiteurs spécifiques pour les balises complémentaires) ;

— des informations extérieures devant s’insérer dans le docu- ment ;

— des informations concernant le balisage du document (par

exemple, l’utilisation des diverses fonctionnalités proposées par SGML) ;

— de la syntaxe du langage utilisé pour construire le balisage (les délimiteurs, les mots-clés et symboles spéciaux qui permettent de construire le système de balisage particulier à l’application) ;

— des modèles de document ;

— des instances.

3.5 SGML sans DTD

Envisager de bâtir des applications SGML sans DTD est une démarche conceptuellement déroutante, voire régressive, pour un spécialiste SGML. C’est pourtant l’approche adoptée par les concep- teurs de la partie Web du réseau Internet à travers HTML à tâtons au départ, plus formellement par la suite.

Créé pour satisfaire au besoin croissant d’une utilisation profes- sionnelle de l’Internet, le concept d’Intranet a rapidement atteint les limites de HTML comme norme d’échanges d’applications docu- mentaires professionnelles. XML est ainsi né et se positionne d’emblée comme la (future) norme pour les applications Web-Intra- net.

Du point de vue du spécialiste SGML, ces deux spécifications apparaissent simplement comme des profils d’applications SGML.

H 7 138 12

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

Nous donnons ci-après un aperçu de leurs philosophies. Leurs notions de bases ne présentent pas de difficultés particulières pour les personnes familières de SGML. Elles sont même d’un niveau conceptuel moindre. Leur exposé n’entre cependant pas dans le cadre restreint du présent article. Les lecteurs intéressés pourront consulter les documents cités en [Doc H 7 138].

3.5.1 HTML

HTML est conçu sur le principe du balisage procédural, à ceci près que le balisage est pensé non pour permettre le formatage des documents, mais essentiellement orienté par la navigation hyper- textuelle (ce qui d’une certaine façon revient au même, étant l’exploitation électronique de l’information) sur le réseau Internet, depuis un poste client quelconque. On peut classer les balises HTML en trois catégories :

— les balises d’affichage des documents, qui organisent l’infor- mation selon la logique documentaire ;

— les balises servant aux renvois intradocumentaires ou aux appels d’objets externes ;

— les balises de localisation des serveurs d’information.

Toutes ces balises font abondamment appel au mécanisme SGML des attributs, pour gérer la localisation de l’information, ou pour indiquer les caractéristiques de l’affichage de l’information (taille des caractères, mise en évidence, etc.). Les experts SGML ont par la suite entrepris l’écriture d’une DTD HTML, considérant que l’ensemble des balises de ce langage ad hoc pouvaient s’articuler au sein d’une grammaire cohérente qui, moyennant la spécification d’une déclaration SGML adaptée, pou- vait s’interpréter comme un modèle de document sens SGML. Cette DTD n’a cependant pour unique intérêt que le fait de ranger HTML au nombre des applications SGML. Conçu en effet dans le seul but d’être accessible en consultation, le document HTML ne se soucie pas d’être valide au sens SGML. La visualisation du docu- ment depuis un poste client équipé d’un navigateur HTML tient lieu de parsing. La DTD est donc condamnée à demeurer implicite, du moins dans l’optique actuelle du Web. HTML est donc considéré désormais comme un profil application SGML destiné à la normalisation des applications Web. La version 4.0 de cette spécification est en cours de définition et devrait conte- nir des mécanismes normalisés de localisation incluant URL, requê- tes SQL et noms de fichiers.

3.5.2 XML

3.5.2.1 Objet de XML

Projet du W3C, XML (eXtensible Markup Language) vise la diffu- sion, à travers le Web, de véritables instances SGML. La spécifica- tion peut donc s’entendre (comme le suggère ce nom) comme une extension de HTML permettant à l’utilisateur de définir ses propres balises. Comme nous l’avons indiqué en introduction, XML est en fait une restriction particulière des possibilités de SGML, ce qui est la définition même d’un profil d’application.

On peut donc schématiquement situer XML entre SGML et HTML. Sa naissance a été suscitée par les limites rencontrées dans l’utilisa- tion de ces deux dernières normes, pour la réalisation d’applications Web professionnelles. Ces limites peuvent se résumer dans les deux points qui suivent :

— la structuration insuffisante et l’absence de sémantique dans

l’approche HTML (et donc le trop peu de possibilités d’indexation des documents) ;

— la lourdeur de mise en œuvre dans l’approche SGML, due pour

l’essentiel à la présence obligatoire du modèle de document (DTD), ce qui exige la présence d’outils d’analyse de conformité à toutes les étapes le long d’une chaîne documentaire SGML.

En dehors de quelques particularités telles que la syntaxe <TAG/> pour la balise de fin des éléments déclarés EMPTY, l’essentiel des notions XML sont des clauses restrictives à partir des concepts SGML ; tel est le cas par exemple de l’interdiction par XML de l’omission de balisage.

XML spécifie des mécanismes hypertextes pour les applications Web, en prenant appui sur les mécanismes d’adressage HyTime, permettant notamment la définition de liens typés et de liens à cibles multiples.

L’évolution de XML prévoit la spécification de feuilles de style nor- malisées basées sur la norme DSSSL.

Signalons, pour terminer, que le jeu de caractères de référence pour les documents XML est UNICODE.

3.5.2.2 « Document bien formé » au sens XML

Le « document bien formé » est la seule notion XML que nous pré- sentons ici. Nous renvoyons à la lecture du document [6] édité par le W3C, pour plus de détail sur le contenu de la spécification. Pour une présentation introductive, voir l’article de F. Chahuneau [7].

La notion XML de « document bien formé » ne s’apparente que de loin à la notion de validité au sens SGML (conformité à un modèle), la présence de la DTD n’étant plus requise pour les documents XML.

La définition ci-après est une interprétation de la définition for- melle du document officiel de la spécification XML. La définition exacte nous conduirait à un exposé détaillé des notions XML soumi- ses aux contraintes WFC (well-formedness constraint), ce qui est hors du propos du présent article.

Un document texte est dit bien formé au sens XML si la struc- ture reconstituable à partir de son balisage est complète et fer- mée, et peut être mise en bijection avec l’ensemble des nœuds d’un arbre hiérarchique.

La notion de fermeture implique une forte exhaustivité locale du document (suppression des références externes).

Cette définition implique la notion d’héritage, mais aussi un niveau de déterminisme élevé quant au contenu des instances d’une telle DTD, d’où la suppression de nombreuses possibilités de SGML, au nombre desquelles :

— les inclusions et les exclusions ;

— les définitions récursives ;

— les références externes pour le contenu des attributs ;

— les valeurs par défaut CURRENT et CONREF.

La notion de « document bien formé » fait de XML un profil SGML réductible à des grammaires assez simples et complètement expri- mables au moyen d’expressions régulières. Il s’ensuit qu’à la diffé- rence de SGML le développement d’outils d’analyse et la mise en œuvre d’applications XML sont relativement simples et rapides.

3.5.2.3 Conclusion

XML allie les capacités de structuration de SGML à la souplesse de HTML, en permettant d’une part la définition de structures nou- velles (balises) par l’utilisateur, d’autre part le balisage, le traitement et l’échange de documents avec la possibilité d’omettre la DTD. Dans l’optique de la réalisation d’applications Web-Intranet, XML cumule en quelque sorte les avantages de SGML et HTML.

Il y a fort à parier que le champ d’utilisation de XML ne se limitera pas aux applications Web-Intranet. Dans de nombreuses autres applications en effet, les utilisateurs souhaitent un « allégement » de SGML, tant il est vrai que cette norme leur apparaît comme une affaire de spécialistes.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 13

SGML

3.6 Quelques grandes applications SGML

De nombreux projets et applications SGML ont vu le jour à travers le monde, depuis la parution de la norme. SGML est progressive- ment entré dans la culture des entreprises. Nous citons ci-après quelques applications d’envergure, illustrations de ce dynamisme de SGML.

CALS (Continuous Acquisition and Life-cycle Support) est une Ini-

tiative bien connue du ministère américain de la Défense (DoD - Department of Defense), que l’on ne saurait limiter à SGML. Au sein du corpus des normes adoptées par CALS, SGML a un rôle central, en tant que norme d’intégration de données documentaires hétéro- gènes. L’envergure de CALS et son impact tant sur l’industrie améri- caine que sur les partenaires des États-Unis ont contribué au rayonnement de SGML, dès les années qui ont suivi la parution de la norme.

L’ association des éditeurs américains (AAP - Association of Ame-

rican Publishers) a conçu des DTD pour ses documents courants (livres, articles, etc.).

Le syndicat de l’édition a conduit un travail similaire en France,

avec d’ailleurs plus de rigueur dans l’écriture formelle.

Oxford University Press a bâti une application SGML pour le

Oxford English Dictionary.

AECMA (Association Européenne des Constructeurs de Matériel

Aérospatial) a conçu des DTD pour les modules d’information (data

modules) tels que définis dans sa spécification AECMA 1000D. Les systèmes documentaires des avions Rafale et Eurofither sont basés sur cette spécification.

SPEEDOC (Système de Production et d’Exploitation Électronique

de la Documentation) est le programme lancé en France en 1988 par la Direction des Constructions Navales, pour l’informatisation de la documentation des SNLE/NG (Sous-marin Nucléaire Lanceur d’Engins/Nouvelle Génération). Il s’agit historiquement du tout pre- mier projet français mettant en œuvre une architecture documen- taire entièrement conçue autour de SGML.

TEI (Text Encoding Initiative) est très utilisée dans les milieux de

la recherche en sciences humaines pour le codage des documents anciens [8].

4. Positionnement de SGML dans le contexte normatif

Il s’agit ici de situer SGML non dans le contexte normatif général, mais par rapport au corpus de ses « normes satellites », c’est-à- dire :

— les normes dérivées de SGML (HyTime, SMDL) ;

— les normes associées à des processus mettant en œuvre des données SGML (DSSSL, SPDL).

4.1 HyTime

HyTime (Hypermedia Time-based structuring language), exten- sion-application de SGML, est parue en 1992, sous la référence ISO/IEC 10744 (cf. [Doc H 7 138]). HyTime est une modélisation spatio-temporelle étendant aux hyperdocuments les principes de descriptions génériques définis par SGML.

Un hyperdocument est une structure d’informations mêlant des données hétérogènes (textes, graphiques, sons, séquences ani- mées, etc.) éventuellement réparties sur des médias différents, et restituées à l’utilisateur final suivant un scénario prédéfini.

La notion centrale de HyTime est la forme architecturale, dont les différents constituants d’une DTD (éléments, liens, etc.) peuvent être considérés comme des instances, au sens des catégories définies au paragraphe 2. HyTime définit un langage de requête pour l’accès aux constituants de l’hyperdocument.

Unique standard permettant la modélisation des hyperdocu- ments, HyTime, assure la pérennité des données manipulées indé- pendamment des moyens matériels et logiciels utilisés, et assure ainsi l’indépendance des utilisateurs vis-à-vis des applications « clés en mains ».

4.2 SMDL

SMDL (Standard Music Description Language ISO/IEC 10743) (cf. [Doc H 7 138]) est une application-extension SGML pour la description et l’échange électronique de documents musicaux. SMDL est à l’origine de l’approche temporelle de la modélisa- tion utilisant la syntaxe SGML, idée reprise par la suite par HyTime. On pourrait interpréter SMDL comme une structuration SGML du temps.

4.3 DSSSL

Longtemps attendu par tous les acteurs du monde éditorial, DSSSL (Document Style Semantics and Specification Language ISO/IEC 10179) (cf. [Doc H 7 138]) est la dernière norme conçue par le même comité international ayant travaillé il y a quelques années à la définition de la norme SGML.

DSSSL vient compléter la modélisation des données (SGML, HyTime) par la modélisation des traitements réalisables sur ses don- nées, le formatage en particulier.

Elle définit à cet effet un langage permettant l’expression formelle et rigoureuse :

— des spécifications de présentation et autres traitements auto- matiques d’instances SGML (textes balisés) ;

— des traitements réalisés par une gamme de formateurs la plus

large possible, des outils natifs aux composeurs actuels, à l’aide de traducteurs spécifiques.

Imaginée au départ pour standardiser la manière d’indiquer les styles et actions de composition associés à un texte balisé selon une DTD SGML, cette spécification s’est en fait généralisée en véritable langage de manipulation d’instances SGML, la composition appa- raissant comme un cas particulier de telles manipulations.

DSSSL est basé sur une « vue base de données » d’une instance SGML. Le fichier (en entrée d’un processeur DSSSL) n’est donc pas parcouru séquentiellement. C’est ainsi que la spécification a intro- duit un langage de requête permettant l’accès direct à une partie donnée du document (instance SGML).

4.4

SPDL

SPDL (Standard Page Description Language ISO/IEC 10180) (cf. [Doc H 7 138]) est un langage de description de page stan- dardisant (à travers des notions telles que celle de pavé) d’un document composé, c’est-à-dire le format de sortie d’un com- poseur. L’objectif visé est la garantie de l’échangeabilité du

H 7 138 14

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

document formaté, permettant ainsi l’impression papier ou équivalent électronique (consultation à l’écran en mode page) par les outils capables d’interpréter SPDL.

L’essentiel des experts ayant contribué à l’élaboration du standard sont des professionnels du secteur de l’édition classique, plus parti- culièrement de la composition. Les standards de fait tels que Post- cript d’Adobe System Inc visent des objectifs que SPDL essaie d’atteindre dans un cadre consensuel.

5. Évolutions dans les années à venir

À l’examen des travaux en cours autour de SGML, deux tendan- ces opposées se dégagent : l’une dans le sens du renforcement des capacités conceptuelles de la norme, l’autre dans le sens d’une sim- plification visant une mise en œuvre facile.

5.1 Renforcement conceptuel

Cette tendance est celle des experts au sein du JTC 1/SC 18/WG 8 de l’ISO/IEC. Elle s’inscrit dans la démarche qui a donné naissance à SGML : décrire le plus précisément possible les documents, en fai- sant abstraction des idées de traitement qui leur sont applicables. La mise en œuvre des applications est l’affaire des utilisateurs et le champ naturel de la compétition entre prestataires divers : consul- tants, fournisseurs de logiciels spécialisés, intégrateurs, etc.

La révision de SGML est ici envisagée comme une démarche d’unification de la norme et des parties purement descriptives de ses deux principales normes satellites, à savoir DSSSL et HyTime.

Le corps de la norme pourrait ainsi notamment hériter :

— de la notion abstraite de grove introduite par DSSSL ;

— des mécanismes d’adressage et de liens issu de HyTime.

Seraient alors laissées dans les normes satellites les notions consacrées aux traitements des documents (ou, plus précisément, des structures d’informations) décrits par la nouvelle version de SGML. Ainsi, par exemple, resteraient dans DSSSL les notions liées aux styles et à la transformation d’instances, mais aussi le langage de requête (qui par ailleurs unifie les approches HyTime et DSSSL).

Fondamentalement, SGML garderait son originalité comme méta- langage, mais gagnerait en pouvoir de conceptualisation et, corol- laire naturel, en complexité de mise en œuvre.

5.2 Vers des profils spécialisés

Les utilisateurs sont à l’origine de cette tendance, même si les tra- vaux qui en sont issus restent l’affaire de spécialistes au sein de groupes d’intérêts tels que le W3C.

Il ne s’agit plus ici de standardiser quelques grandes DTD applica- tives, mais de modifier la norme elle-même, pour en obtenir des ver- sions allégées répondant au besoin d’une mise en œuvre simplifiée. XML évoqué au paragraphe 3.5.2 procède d’une telle démarche.

Ces langages dérivés génèrent parfois des concepts propres ou des singularités syntaxiques qui créent des divergences avec le corps de la norme. Ainsi, par exemple, la compatibilité XML SGML sera obtenue au prix d’un correctif technique (en

cours) au standard ISO 8879 (SGML), permettant la prise en compte des aspects propres à XML.

5.3 De nouvelles normes satellites

Pour clore cette partie consacrée aux perspectives, nous évo- quons brièvement deux projets consacrés à des aspects particuliers d’exploitation de structures d’informations SGML.

SMSL

SMSL (Standard Multimedia/hypermedia Scripting Language) est un projet mené conjointement par deux groupes de travail du JTC 1/ ISO/IEC : le SC 18/WG 8-SGML et le SC 29/WG 12-MHEG. Ce travail vise le développement d’un standard assurant la compatibilité et la portabilité, entre plates-formes hétérogènes, de scripts interactifs pour le multimédia. Le projet est pour l’instant en veilleuse.

Topic Navigation Map

Conduit par le JTC 1/SC 18/WG 8 de l’ISO/IEC, ce projet vise la for- malisation de l’enrichissement sémantique de documents SGML existants. En d’autres termes, il s’agit de décrire la manière d’établir des rapprochements, d’ajouter de l’information et de la pertinence à des documents existants, sans modifier leur contenu initial ni inter- férer sur leur cycle de vie. Un réseau de liens est créé « par-dessus » les documents.

6. SGML et l’ingénierie documentaire

Après une définition de l’ingénierie documentaire, nous allons montrer en quoi SGML se présente comme l’un des meilleurs outils conceptuels, pivots dans la conception et la mise en œuvre d’archi- tectures fonctionnelles d’ingénierie documentaire.

6.1 Systèmes éditoriaux classiques

La « vue document » peut être l’expression caractérisant la démarche des systèmes éditoriaux classiques. L’ensemble des moyens organisationnels et techniques d’une telle démarche est orienté vers la production du document, le document étant ici un produit fini d’édition, c’est-à-dire des informations organisées et for- matées selon l’idée classique du livre, quels que soient par ailleurs leurs supports de diffusion.

Polarisés par la production du document, les moyens conceptuels mis en œuvre par le système éditorial classique le sont aussi. Ainsi, par exemple, la modélisation du document sera naturellement orientée par les problèmes de formatage de document, en priorité sur d’autres problèmes documentaires.

Le rôle de plus en plus important de l’informatique dans les métiers de l’édition est essentiel dans l’évolution que connaît depuis près d’une décennie le système éditorial classique, vers l’ingénierie documentaire.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 15

SGML

6.2 Ingénierie documentaire

L’ingénierie documentaire peut se définir comme l’ensemble des activités de conception, de mise en œuvre et de maintien en condition opérationnelle d’un système d’information documen- taire.

La notion de système d’information s’entend ici au sens global d’un ensemble de processus élémentaires. Il s’agit d’un ensemble de processus associés aux traitements (génération, gestion ou inter- prétation) de données documentaires hétérogènes. En somme, les données sont considérées sur leur cycle de vie, de leur acquisition à leur diffusion sous forme de produits d’édition, en passant par leur mise à jour et la prise en compte des retours d’utilisation.

La vue « système d’information documentaire » marque ici la dif- férence essentielle avec les systèmes éditoriaux classiques. L’apport de l’informatique dans ce domaine s’est accompagné d’une démar- che méthodologique dont nous donnons ci-après la substance sous forme de quelques principes.

Les principes énoncés ici ne sont pas exhaustifs. Ils ont histori- quement guidé la mise en œuvre de l’ingénierie documentaire dans le cadre de l’initiative CALS.

Principes

Pérennité des données véhiculées à travers l’ensemble des pro-

cessus du système d’information documentaire.

Suppression des « îlots d’information » (un système est fait

d’îlots, dès lors qu’une de ses composantes se trouve déconnectée du reste du système. La pertinence des données n’est plus alors

assurée).

Indépendance du système d’information vis-à-vis des plates-

formes logiciels et matériels.

Minimisation du Coût Global de Possession (LCC — Live-Cycle

Cost — dans la terminologie CALS).

Ces principes impliquent :

— la continuité sémantique, à travers le flux de données, d’un

processus aux processus connexes ;

— le bouclage et l’itération possible des processus (ce qui impli-

que en particulier la remontée, vers les processus amont, des don-

nées en retour d’utilisation) ;

— la notion de système d’information intégré.

Les processus au sein d’une architecture d’ingénierie documen- taire peuvent se répartir en trois grandes activités primaires :

l’acquisition des données, le stockage et la gestion des données, la diffusion et l’exploitation des données. Le rappel de l’architecture globale et une brève description de chacune de ces activités nous permettront de positionner SGML au sein de l’architecture fonction- nelle d’un système d’information documentaire, mais aussi de don- ner une classification des outils SGML.

Architecture globale

En utilisant la méthode IDEF0, l’architecture globale peut se décli- ner comme sur la figure 2.

Par affinement progressif, les trois principales activités repérées peuvent elles-mêmes être déclinées en sous-activités jusqu’au plus bas niveau, selon la même syntaxe de représentation IDEF0.

Acquisition

L’acquisition des données met en œuvre deux types de processus, liés à l’origine des données. Elle s’opère par saisie directe ou par transcodage, selon que les informations sont générées ex nihilo ou récupérées de sources existantes, électroniques ou même papier.

Gestion : bases d’information modulaires

Nous sommes ici au cœur de l’architecture globale.

L’activité de gestion des données s’appuie sur la notion de base de données, en tant qu’ensemble structuré de données accessibles par l’ordinateur pour satisfaire simultanément plusieurs utilisateurs

en un temps opportun. Pour mémoire, un Système de Gestion de Base de Données (SGBD) est le logiciel qui permet d’interagir avec une base de données.

Dans le domaine spécifique de l’ingénierie documentaire, le concept de Bases d’Informations Modulaires est apparu, ces derniè- res années, pour faire face à la gestion d’informations élémentaires, susceptibles d’être utilisées dans des documents plus complexes.

L’idée initiale des Bases d’Information Modulaires est la constitu- tion, pour un domaine donné (bibliothèque, entreprise, avionique, etc.), d’une base de primitives documentaires, à partir de laquelle pourront être générés automatiquement tous les documents relatifs au domaine, l’objectif étant la « réutilisabilité » de ces primitives documentaires, dans un souci de cohérence et de non-redondance.

Définitions • Une primitive documentaire (ou module, ou granule d’infor- mation) est une unité d’information autosuffisante. • Une unité d’information est dite autosuffisante lorsque son contenu est signifiant en soi.

Ces définitions signifient que la pertinence sémantique de la pri- mitive documentaire est complète dès lors que l’on a connaissance de son contenu, ce contenu étant exhaustif, en ce sens que toutes les informations nécessaires à la pertinence sémantique sont physi- quement présentes ou référencées avec possibilité d’accès dynami- que au contenu des données.

Plusieurs primitives documentaires peuvent ainsi partager des données communes comme une illustration ou une référence bibliographique.

On peut à présent donner la définition suivante.

Une base d’information modulaire est caractérisée par un modèle de SGBD mettant en œuvre des primitives documentai- res dans un domaine donné.

L’activité de gestion des données au sein des architectures d’ingé- nierie documentaire s’appuie sur des bases d’information modulai- res.

Rappelons pour finir que, quelle que soit la méthode suivie pour constituer l’ensemble des modules d’information, elle doit obéir à deux principes :

— l’exhaustivité (la base d’information doit contenir toutes les informations permettant de répondre à toute demande documen- taire d’un domaine donné) ;

— la non-redondance (à travers le partage de l’information, la

base d’information doit éviter autant que possible la duplication des données).

C’est en cela qu’une base d’information modulaire dans un domaine donné est considérée comme une « base documentaire orthonormée » pour le domaine en question.

Diffusion

Trois types de diffusion des données sont aujourd’hui considérés comme classiques :

— la diffusion de type documentaire (l’organisation et la diffusion de l’information sous forme de documents, au sens classique), sur support papier ou non ;

— la diffusion électronique d’extraits de la base d’information sous forme de lots de primitives documentaires ;

— la diffusion en ligne des deux catégories précédentes.

H 7 138 16

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

Contrôle local Contrôle global Contrôles spécifiques Données structurées Acquérir Modules d'information
Contrôle local
Contrôle global
Contrôles spécifiques
Données
structurées
Acquérir
Modules
d'information
Stocker / Gérer
Diffuser
Transcodage,
SGBD
saisie directe

Formatage / composition

Données

brutes

Données

consultables

Figure 2 – Architecture globale selon la méthode IDEF0

Dans chacun de ces cas, un processus de composition est néces- saire pour formater les données de manière à les rendre humaine- ment exploitables par destinataires. On peut compléter ses modes de diffusion par la diffusion/exploi- tation interactive qui a donné lieu à quelques travaux importants ces dernières années [9] [10] [11] [12].

6.3 SGML et l’ingénierie documentaire

Après l’exposé du paragraphe précédent, SGML et ses normes satellites apparaissent comme l’ensemble cohérent de modèles, for- mats et méthodes susceptibles de faciliter l’approche de l’ingénierie documentaire selon les principes rappelés au paragraphe 6.2. Reprenant la figure 1 et en prenant quelques libertés avec IDEF0, on obtient le schéma de la figure 3. Le principe du système d’information intégré est presque naturel ici, les processus est les formats des données étant normalisés par SGML et ses normes satellites. La notion de « SGML repository » est l’approche SGML des bases d’information modulaires.

6.4 Classification des outils SGML

Nous ne dressons pas ici une typologie des outils SGML du mar- ché, par souci de neutralité vis-à-vis des fournisseurs. Il s’agit plutôt d’établir quelques critères de choix des outils, selon leur positionne- ment au sein d’une architecture globale d’ingénierie documentaire.

Parseur Les parseurs sont les outils d’analyse et de validation des docu- ments SGML. Ils peuvent être intégrés à divers outils de la chaîne documentaire, ou utilisés seuls pour valider les documents avant leur transmission à un partenaire ou à la réception par un destina- taire. Ils peuvent aussi être utilisés seuls, pour générer la forme canonique des documents SGML. Le marché offre un choix d’outils, allant des parseurs simples basés sur des générateurs d’analyseurs syntaxiques comme YACC, aux parseurs puissants capables d’effectuer certaines analyses

sémantiques. Le critère de choix sera essentiellement le niveau de contrôle et de validation que l’utilisateur souhaite obtenir pour les documents en entrée ou en sortie de son application.

Outils d’acquisition des données

Les éditeurs SGML (saisie directe des données)

Les quelques critères à prendre en compte sont :

— les délais d’introduction d’une nouvelle DTD (paramétrage) ;

— la possibilité de saisie contextuelle guidée et contrôlée ;

— la présence d’outil de validation intégré ;

— les capacités ergonomiques (approche WYSIWYG, représenta- tion arborescente, etc.).

Les transcodeurs (récupération)

Les quelques critères à prendre en compte sont :

— les délais d’introduction d’une nouvelle DTD (paramétrage) ;

— les types de formats d’entrée acceptés.

Stockage et gestion des données

Des gestionnaires de fichiers aux bases de données documentai- res, en passant par les bases de données relationnelles et les bases de données objets, aucune des technologies disponibles n’est utili- sable en l’état, pour la mise en œuvre du concept de SGML reposi- tory telle que nous l’avons présentée. Cela est dû au caractère métalangage de SGML. Le choix des outils est ici déterminé par leur dimensionnement aux applications à mettre en place.

Restitution des données

Les outils considérés ici mettent en œuvre des transformations et des traitements sur des documents SGML. Un des critères impor- tants à considérer sera donc la possibilité de réaliser ces traitements conformément aux normes satellites de SGML conçues à cet effet.

Les composeurs (formatage)

Les quelques critères à prendre en compte sont :

— l’acceptation de DSSSL et les délais d’introduction d’une nou- velle feuille de styles ;

— les capacités de validation SGML et DSSSL ;

— les capacités à générer des données consultables au format

SPDL ;

— le mode opératoire et l’efficacité : travail en batch ou « à la volée » ?

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

H 7 138 17

SGML

Parsing local Parsing global DSSSL Données Instances brutes Saisie / SGML Transcodage Fragments SGML SGML
Parsing local
Parsing global
DSSSL
Données
Instances
brutes
Saisie /
SGML
Transcodage
Fragments
SGML
SGML
repository
Formatage /
Diffusion
Données

SPDL

Figure 3 – Architecture globale dans le contexte SGML

Les navigateurs (consultation)

Les quelques critères à prendre en compte sont :

— les capacités d’interprétation des données consultables au for- mat SPDL ;

— les capacités de validation SPDL.

7. Conclusion

Après une décennie d’existence et en dépit de son caractère de métalangage qui en fait un modèle pas simple a priori, SGML peut être considéré comme un succès, ainsi que le témoignent ses nom- breuses applications.

Ces applications se retrouvent aujourd’hui dans tous les secteurs d’activité aux prises avec des problèmes de conception et de mise en œuvre de documentations structurées.

Les ressorts conceptuels de la norme se sont affinés, en particu- lier sous l’impulsion des travaux menés dans le cadre des normes satellites. Il en résulte un abandon de certaines notions dont l’utilité n’était pas manifeste, telles que les références abrégées. Il se des- sine une évolution de la norme vers un corps de concepts de base assez abstraits, toujours sous-tendus par la puissance conceptuelle de l’approche métalangage.

Dans le même temps apparaissent des profils d’applications qui visent une plus grande facilité de mise en œuvre et un plus grand nombre d’utilisateurs. Ces différents profils ne sont pas nécessaire- ment des candidats à la marginalisation de la norme elle-même. Ils signifient peut-être simplement que SGML reste d’un accès difficile pour un grand nombre d’utilisateurs. L’accroissement de l’audience de SGML passe alors (du moins pour l’instant) par quelques simpli- fications, la tendance commune à toutes ces simplifications étant un renoncement à l’approche métalangage.

Tant pour son intérêt théorique que pour ses possibilités d’appli- cation, on peut prévoir pour SGML un nombre d’utilisateurs en aug- mentation dans les années à venir.

H 7 138 18

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

SGML

par Luc SONKÉ

Docteur en mathématiques Président de STSI-SA (Société des Technologies et Systèmes d’Information), Paris

[1]

GOLDFARB (C.F). – The SGML Handbook. Oxford University Press (1991).

[2]

BRYAN (M.). – SGML an author’s guide to The Standard Generalized Markup Language.

Addison-Wesley Publishing Company (1988).

[3]

Van HERWIJNEN (E.). – Practical SGML. Kluwer Academic Publishers second printing

(1991).

[4]

DGA/SLM/D6-9102. – Guide d’utilisation de SGML. Ministère de la Défense - Délégation générale pour l’Armement (sept. 1991).

[5]

Hypertext Markup Language (HTML) V 3.2.

Wold Wide Web Consortium (mars 1997).

Bibliographie

[6] The eXtensible Markup Language (XML), Draft version n o 2. Wold Wide Web Consor- tium (avr. 1997).

[7]

CHAHUNEAU (F.). – SGML sans DTD. Docu- ment numérique vol 1 n° 1, Hermès (fév.

1997).

[8]

ROLE (F.). – DTD/TEI H 7 143 – Techniques de l’Ingénieur, traité Informatique vol. H4 (1998) à paraître.

[9]

MIL-M-87268. – Interactive Electronic Techni- cal Manuals (IETM) : General Content, Style, Format, and User-Interactive Requirements.

DoD (oct. 1992).

[10] MIL-D-87269. – Data Base, Revisable : Inte- ractive Electronic Technical Manuals, for the support of. DoD (oct. 1992).

MIL-Q-87270. – Quality Assurance Program :

Interactive Electronic Technical Manuals and Associated Technical Informations ; Require- ments for. DoD (oct. 1992).

[12] Metafile for Interactive Documents (MID), Specification for the Encoding of Interactive Documents. US Navy (nov. 1994).

Ouvrage

[11]

TRAVIS et WALDT. – The SGML implementation guide. Springer Verlag (1995).

Normalisation

SGML a officiellement été adopté comme norme ISO (International Organi- zation for Standardization) en octobre 1986 sous la référence ISO 8879. L’AFNOR a, quant à elle, adopté la norme en 1990, sous la référence NF EN 28879. La norme a reçu en 1988 un amendement (Amendement 1) qui est incorporé au texte de référence. Conformément aux procédures de l’ISO, une première révision de la norme a eu lieu en 1991 et une deuxième en 1996. Aucune de ces révisions n’a pour l’instant donné lieu à la diffusion d’une nou- velle version de la norme. Un rectificatif technique a cependant été publié en 1996.

ISO 8879 1986 Information processing - Text and office systems - The Standard Generalized Markup Language (SGML). [Traitement de l’information - Systèmes bureautiques - langage normalisé de balisage généralisé (SGML)] Incorpore l’Amendement 1-1988. Rectificatif technique 1-1996. Technical Corringendum to The Standard Generalized Markup Language (SGML) (en anglais seulement).

ISO 8632-1 1992 Computer Graphic Metafile (CGM) for the storage and transfer of picture description information (Technolo- gie de l’information - Infographie - Metalfichier de stockage et de transfert des informations de descrip- tion - Partie 1 : Description fonctionnelle). Amende- ment 1-1994 - Règles pour profils (en anglais seulement).

ISO/IEC 10179 1996 Information processing - Document Style Semantics and Specification Language (DSSSL). (Technologie de l’information - Langages de traitement - Sémantique de présentation de documents et langage spécifique (DSSSL) (en anglais seulement).

ISO/IEC 10646-1 1993 Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1 : Architecture and Basic Multilingual Plane. (Technologies de l’informa- tion - Jeu universel de caractères codés à plusieurs octets - Partie 1 : Architecture et table numérique) (en anglais seulement). Rectificatif technique 1 : 1996. Nombreux Amendements.

ISO 9069 1988 Information processing - SGML support facilities - SGML Document Interchange Format (SDIF). [Traite- ment de l’information - Facilité de support SGML - For- mat d’échange de documents SGML (SDIF)].

ISO/IEC 10744 1997 Information processing - Hypermedia/Time-based Structuring Language (Hytime). [Technologies de l’information - Langage de structuration temporelle/ hypermédia (HyTime)] (en anglais seulement).

ISO/IEC 10743

1994 Information processing - SGML support facilities - Standard Music Description Language (SMDL).

ISO/IEC 10180

1995 Information processing - Text composition - Standard Page Description Language (SPDL). [Technologies de l’information - Langage de traitement - Langage de description de page normalisée (SPDL)] (en anglais seulement).

Pour consulter ces normes, on pourra faire appel aux adresses suivantes :

http://www.ornl.gov/sgml/wg4

http://www.ornl.gov/sgml/wg8/wg8home.htm

http://www.hightext.com/tnm

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique

Doc. H 7 138 1

P

O

U

R

E

N

S

A

V

O

I

R

P

L

U

S