Historique des langages de description et de SGML

La préhistoire

Aux débuts de l'histoire de l'informatique, l'ordinateur sert à faire du traitement par lots (batch). Il est essentiellement une machine à calculer, prenant des données en entrée, et régurgitant d'autres données en sortie. Les données sont donc sérialisées pour pouvoir alimenter l'ordinateur, et seuls des codes de contrôle permettent de les formatter. Ces caractères spéciaux, insérés au milieu du code, forment un marquage procédural des données.

L'émergence de nouveaux concepts

En 1967, William Tunnicliffe, de la GCA (Graphic Communications Association), fait une présentation au Canada dans laquelle il expose la séparation du contenu d'un document d'avec son format. A la fin des années 60, Stanley Rice (New York) propose l'idée d'un catalogue universel de balises paramétrables pour la description d'une structure éditoriale. Ces idées introduisent l'utilisation d'un nouveau type de marquage dans les données : le marquage descriptif. Le comité de composition de la GCA (composition committee) développa alors GenCode. A ce stade, il est reconnu que plusieurs marquages différents sont nécessaires suivant le type de document considéré, et que les documents peuvent être structurés en plusieurs documents plus petits. Le projet évolua pour aboutir au comité GenCode.

En 1969, sur les idées de Rice et Tunnicliffe, Charles Goldfarb, directeur de recherche chez IBM, Edward Mosher and Raymond Lorie inventèrent GML (Generalized Markup Language). GML (qui comprend aussi les initiales de ses inventeurs) permettait d'éditer et formatter du texte, et de traiter et partager de l'information sur des systèmes hétérogènes. GML introduisit le concept de type de documents, et une structure arborescente du marquage. Goldfarb continua ensuite ses recherches, créant de nouveaux concepts comme les références ou les types de documents multiples, qui furent intégrés ensuite à SGML.

Le développement de SGML

En 1978, le comité sur le traitement de l'information de l'ANSI (American National Standards Institute) créa un nouveau comité (Computer Languages for the Processing of Text committee). Goldfarb fut invité à rejoindre ce comité pour élaborer une norme basée sur GML. Malgré le peu de succès de GenCode, le GCA rejoint le comité.

Le premier brouillon du futur standard SGML est publié en 1980. En 1983, le GCA reconnaît la sixième version de SGML comme une norme : GCA 101-1983. Les premiers clients importants sont les département de la finance (IRS) et de la défense (DoD) américains. Enfin, en 1984, l'organisation ISO (International Organization for Standardization) rejoint le comité et en 1986 SGML devient une norme internationale.

Introduction

SGML est un standard international définissant des méthodes de représentation d'un texte électronique, indépendamment du matériel et du système utilisés. SGML ne définit pas un langage, mais le moyen de décrire un langage de description (ou à balises). Il s'agit d'un méta-langage.

SGML introduit :

le marquage descriptif: Les instructions de traitement du texte ne font plus partie du document. Le texte peut-être traité facilement par différents outils (indexation, transformations, affichage, ...), lesquels peuvent facilement ignorer les parties du document qui ne les concerne pas. Il y a indépendance du fond et de la forme.
le type de document: Le type d'un document est uniquement défini par sa structure, donc les éléments autorisés, interdits, et leur disposition. Le type d'un document permet de valider la structure de ce document (à l'aide de parsers). Il apporte une connaissance de la sémantique et permet l'écriture d'outils de traitement plus intelligents.
l'indépendance: Au niveau du document, le marquage descriptif plutôt que procédural apporte une standardisation du marquage. Au niveau du traitement du document, c'est la déclaration SGML qui garantit l'indépendance quant au système. Il devient possible de partager des documents entre systèmes hétérogènes sans perte d'information.

Le document SGML

Le prologue

Tout document SGML est constitué d'un prologue et d'une instance de document. Le prologue sert à définir le langage utilisé dans l'instance de document qui suit. Il contient la DTD (Document Type Definition) et la déclaration SGML.

<!DOCTYPE poem SYSTEM "poem.dtd" [
<!ELEMENT redifined.tag	  - -    (#PCDATA) >
<!ENTITY author         "David Soulayrol" >
<!ENTITY stanza1 SYSTEM "strophe1.sgml" >
<!ENTITY stanza1 SYSTEM "strophe2.sgml" >
]>

Le prologue est introduit par la première ligne, avec le mot-clef DOCTYPE. Il peut être présent dans le document lui-même, ou bien seulement référencé par le document (comme ici avec le mot clef SYSTEM), auquel cas il peut se présenter aussi sous une forme compilée pour le système.

La partie entre crochets appartient aussi au prologue et constitue un sous-ensemble de la DTD (DTD subset). Il permet de définir des entités propres au document, ou de modifier la DTD utilisée. Les définitions écrites dans cette parties sont lues en premier par le parser, et prennent le pas sur les définitions d'une DTD externe car seule la première déclaration compte en SGML.

D'une manière générale, la balise ouvrante <! introduit un contexte SGML. Le contenu de ce contexte est traité selon la syntaxe SGML, et non pas comme le reste du document.

L'instance de document

L'instance de document constitue le document lui-même. Il ne contient que du marquage et des données ou des références, et ne doit contenir aucune nouvelle déclaration. Un moyen efficace de construire des documents importants consiste à déclarer des entités pour chaque module du document comme ici :

<poem id=P1 status="revised">
  <title>Un Poème de &author;</title>
  &stanza1;
  &stanza2;
</poem>

La DTD (Document Type Definition)

La définition de document (DTD) est un ensemble de règles régissant la structure du document SGML. L'écriture d'une DTD est un compromis entre laxisme et rigidité. C'est un exercice qui peut s'avérer difficile, en particulier s'il s'agit de traiter un texte existant. Appliquer une DTD à un texte, c'est aussi l'interpréter, choisir un aspect plutôt qu'un autre.

Déclaration des éléments

Une DTD est un ensemble de déclarations. Les lignes ici définissent un chacune un élément. Chaque déclaration d'élément est constituée de trois parties ; un nom ou groupe de noms, les règles minimisation, et un modèle de contenu (model content). Chaque partie est séparée par des caractères d'espacement (tabulation, nouvelle lignes, ...).

-- Dans la DTD: --
<!ELEMENT poem                - -    (title?, stanza+) >
<!ELEMENT title		      - O    (#PCDATA) >
<!ELEMENT stanza	      - O    (line+) >
<!ELEMENT (line | line2)      O O    (#PCDATA) >

Les règles de minimisation sont constituées d'une paire de caractères qui sont soit - soit O, O signifiant optionnel. Ces caractères représentent respectivement la possibilité de minimisation de la balise de début de l'élément (start-tag) et de celle de fin (end-tag). En dernier lieu cependant, un élément doit toujours pouvoir être distingué de l'élément qui le contient, et de ceux qui le précèdent ou le suivent : dans l'exemple précédent, l'élément line peut ne comporter aucun balise que s'il est le seul fils d'un élément stanza.

Le modèle de contenu, décrit entre parenthèses, spécifie les éléments pouvant être contenus dans l'élément définit. Il peut aussi contenir certains mots-clefs, comme PCDATA ou EMPTY. La DTD peut être vue comme un arbre, dont le tronc est l'élément le plus haut (poem), et dont les branches mènent éventuellement jusqu'aux données textuelles (#PCDATA).

Un élément figurant dans le modèle de contenu peut être immédiatement suivi d'un indicateur d'occurrence. SGML en définit trois : + pour un ou plusieurs, ? pour aucun ou un seul et * pour aucun ou plusieurs.

La syntaxe du modèle de contenu indique aussi l'ordre dans lequel les éléments fils doivent apparaître. SGML définit trois opérateur de séquence ou de groupement : , définit un ordre fixe. & représente un ET : tous les éléments spécifiés doivent apparaître, mais dans n'importe quel ordre. Enfin, | spécifie que seul l'un des éléments proposés peut apparaître.

Les opérateurs présentés ici possèdent tous un nom formel permettant d'être redéfinis dans la déclaration SGML.

Les exceptions

Le modèle introduit jusqu'ici ne permet pas de résoudre le problème induit par des objets flottants (images, notes, ...). Ces objets ne peuvent pas être décrits dans la structure du document... Ou bien ils devraient apparaître à tous les niveaux de cette structure, ce qui pollue inutilement la structure du document et n'est pas envisageable pour de gros ouvrages.

SGML définit deux types d'exception pour pallier à cela. Les liste d'inclusion permettent d'ajouter la possibilité d'apparition d'éléments à n'importe quel endroit d'un modèle de contenu, même ceux définit avec #PCDATA. Cette liste est introduite avec un + après le modèle de contenu.

-- Dans la DTD: --
<!ELEMENT poem - O    (title?, (stanza |couplet)+ )  +(note | variant) >

Les liste d'exclusion, au contraire, permettent d'empêcher l'apparition d'éléments dans un modèle de contenu. Elles prennent le pas sur les listes d'inclusion, et sont introduites avec un - après le modèle de document.

-- Dans la DTD: --
<!ELEMENT title	           - O    (#PCDATA)  -(variant) >
<!ELEMENT (note | variant) - -    (#PCDATA)  -(note | variant) >

Modèles concurrents

Le deuxième problème est la description de deux modèles de document concurrents. SGML permet d'associer plusieurs DTD à un seul document. Toutefois cette faculté du langage est optionnelle et n'est pas toujours implémentée.

Pour faire usage de différentes vues d'un document, il suffit de préfixer les éléments par le nom du modèle auquel ils appartiennent entre parenthèses. Les éléments communs aux deux modèles ne nécessitent pas d'être préfixés.

<!-- Dans l'instance de document: -->
<(poem)stanza><(paged.poem)page> ...

Les attributs

Un attribut apporte une information supplémentaire à une instance particulière d'un élément, sans considération sur son contenu. Les attributs sont introduits dans la balise de début d'un élément uniquement, à la suite de son identifiant sous la forme d'une paire attribut-valeur.

<!-- Dans l'instance de document: -->
<poem id=P1 status="draft"> ...

Une liste d'attributs est introduite par le mot-clef ATTLIST, suivi de l'élément, ou de la liste d'éléments, concerné(s). Suivent une ou plusieurs lignes décrivant chacune un attribut avec son nom, le type de valeur qu'il accepte et sa valeur par défaut.

-- Dans la DTD: --
<!ATTLIST poem
	  id                  ID                                 #IMPLIED
	  status              (draft | revised | published)      draft

Le nom d'un attribut suit les mêmes règles de nommage que tous les autres noms SGML. Il ne nécessite pas d'être unique dans le document, mais seulement dans la liste d'attributs d'un élément donné. L'attribut id possède normalement un sens spécial. Il permet de désigner de manière unique un élément par convention.

La seconde partie d'un attribut peut être un mot-clef ou bien une liste de valeurs admissibles. En plus du mot-clef ID, on peut trouver :

CDATA : n'importe quelles données valides. Elles ne seront pas analysées par le parser.
IDREF : un pointeur sur un autre élément. Introduit un mécanisme de références croisées.
NUMBER : une suite de chiffres uniquement.

La troisième partie indique comment une absence de cet attribut doit être interprétée. Elle peut être un mot-clef ou bien une valeur par défaut. Les mots-clefs peuvent être les suivants :

#REQUIRED : une valeur doit obligatoirement être spécifiée.
#IMPLIED : La présence de cet attribut c'est pas nécessaire.
#CURRENT : la dernière valeur spécifiée est utilisée.

Les entités

Jusqu'ici, nous n'avons décrit le document SGML qu'en suivant scrupuleusement sa structure. Une entité, au contraire, procure un moyen de nommer n'importe quelle partie arbitraire du document, sans aucune considération pour sa structure ; ce peut être une chaîne de caractères ou un fichier entier.

Une entité externe comprend un identifiant SYSTEM et/ou un identifiant PUBLIC ou autre dans sa déclaration. SYSTEM permet de nommer tout objet pouvant être retourné par le système. En théorie, une telle entité peut représenter un fichier, le résultat d'une requête en base de données, le résultat d'un appel à une fonction, ... En pratique, les processeurs SGML implémentent en général seulement l'accès à un fichier.

Les entités sont utiles pour centraliser une définition utilisée de nombreuses fois dans un document : le nom de l'auteur, une référence à un organisme, ... ou exprimer des caractères non représentables sur un système donné.

	  
-- Dans la DTD: --
<!ENTITY author 'Moi' >
<!ENTITY html-dtd SYSTEM "html.dtd"
		       PUBLIC "-//IETF//DTD HTML//EN">

<!-- Dans l'instance de document: -->
&nom-entité; ou &nom-entité, &#charcode

Une entité paramètre est introduite par % plutôt que par & et n'occupe pas le même espace de noms. Elle ne peut apparaître que dans un contexte SGML, et pas dans le document lui-même.

	  
-- Dans la DTD: --
<!ENTITY % TEI.prose 'INCLUDE' >
<!ENTITY % TEI.extensions.dtd 
			SYSTEM 'mystuff.dtd'>

<!-- Dans l'instance de document: -->
%nom-entité; ou %nom-entité

Sections marquées

Il est parfois intéressant de rendre conditionnelle l'apparition de certaines sections d'un document. Il est aussi intéressant parfois, par exemple lorsque l'on inclut des exemples de code, de demander au parser d'ignorer complètement une section donnée afin qu'il ne soit pas perturbé par l'apparition d'un marquage inattendu. Le marquage de sections en SGML permet tout cela.

	  
<!-- Dans l'instance de document: -->
<![ CDATA [
	<exemple>code</exemple>
]]>

Il existe différents mots-clefs permettant d'introduire une section marquée :

INCLUDE : le portion de texte est traitée normalement.
IGNORE : la portion de texte n'est pas du tout traitée par le parser.
CDATA : le portion de texte peut contenir des balises SGML ou des entités, mais qui ne devraient pas être reconnues comme telles par le parser.
RCDATA : même comportement, sauf pour les entités qui seront reconnues comme telles.
TEMP : permet simplement de marquer une section. La portion de texte est traitée normalement.

L'usage de section marquée est particulièrement utile lorsque utilisé conjointement avec des entités paramètre.

	  
<!ENTITY % TEI.prose 'INCLUDE' >
<![ %TEI.prose; [
	...
]]>

La déclaration SGML

Tout document SGML définit un langage dans son prologue et l'utilise dans l'instance de document. En général, les outils implémentant le standard fournissent la syntaxe de référence (reference concrete syntax), celle que l'on a vu jusqu'ici, et quelques jeux de caractères standards : ASCII, EBCDIC. Toutefois, il arrive que la syntaxe de référence ne convienne pas, que la taille maximale autorisée pour les identifiants génériques soit trop petite, etc. Dans ce cas uniquement, la déclaration SGML est requise et doit être placée en tête du prologue.

Globalement, la déclaration apporte des informations sur la structure lexicale de l'application, et la DTD sa structure syntaxique. Elle est constituée d'une liste de sections permettant chacune de paramétrer un aspect du langage définit : le jeu de caractères qu'il utilise, ses spécificités syntaxiques, ses capacités particulières, ...

En pratique, la DTD est importée d'un fichier externe, et la déclaration est incluse depuis ce fichier. L'utilisateur final n'a donc souvent aucune idée de son existence.

Un complément à la DTD

Partie facultative du prologue
Introduction de modifications à la syntaxe de référence du standard

	  
<!SGML "ISO 8879:1986"
	-- La déclaration SGML ici:             --
	-- CHARSET                              --
	-- SYNTAX                               --
	-- FEATURES				--
	-- SCOPE				--
	-- CAPACITY				--
	-- APPINFO				--
>

Définition syntaxique du document

La section CHARSET définit le jeu de caractères valides des documents appartenant à une application donnée. La description d'un jeu de caractères nécessite trois informations : les caractères du jeu du document, les codes de caractères, et les liens entre ces deux groupes. Cette description étant très longue, SGML permet de s'appuyer sur un standard. Le standard utilisé est donné avec la balise BASESET. Quelques exemples de jeux standards :

ISO 646 (7-bit ASCII)
ISO 8859-1 (ISO Latin-1)
ISO 10646 (Superset de Unicode sur 4 octets)

La balise DESCSET permet de modifier le mapping définit par le standard entre caractères et codes. Cette sous-section est composée de trois colonnes : la première est le code du caractère du jeu que l'on définit. La seconde est un nombre, permettant de définir une séquence en une ligne. La troisième est le code du caractère du jeu de base, ou bien l'attribut UNUSED, spécifiant une non-appartenance au jeu définit.

	  
0	9	UNUSED
127	1	31

Attention: le jeu de caractère définit ici n'est pas le même que le jeu utilisé pour encoder le fichier abritant le document (external charset encoding). Dans la pratique, le jeu de caractères définit ici est seulement utilisé par un rédacteur dans l'utilisation des entités numériques.

SGML possède aussi une notion de jeu de caractères système (system character set). Pour traiter un fichier, l'outil SGML doit transformer le fichier encodé pour le faire correspondre à la description donnée dans la déclaration, ou au contraire, adapter le jeu définit dans la déclaration à celui du système.

SGML a une limite à l'indépendance : comment lire une déclaration SGML dont on ne connaît pas l'encodage a priori ? C'est impossible, et le standard note à ce propos qu'il faut soit l'identifier avec un nom ou un numéro, soit utiliser une copie lisible par l'homme.

Définition lexicale du document

SYNTAX [PUBLIC reference [SWITCHES codes] ]

La section SYNTAX définit la application concrete syntax, qui est la syntaxe d'un document de cette application. Elle est complémentaire à la reference concrete syntax qui est la syntaxe des applications SGML, et qui définit le format des spécifications SGML comme les déclarations.

La balise SYNTAX peut être suivie du mot-clef PUBLIC qui introduit une syntaxe de référence à partir de laquelle celle-ci sera définie. Si ce mot-clef est utilisé, le mot-clef SWITCHES peut ensuite permettre à deux caractères d'alterner leur rôle respectif. Si ces mots-clefs facultatifs ne sont pas utilisés, l'ensemble des sous-sections de la syntaxe doivent être définies. Ces sous-sections sont :

le jeu de caractère utilisé pour la définition de la syntaxe,
les combinaisons de bits (ou codes caractères) qui ne devraient pas tre utilisées dans un document,
les caractères spéciaux (function characters) : espaces, masquage, ...
les délimiteurs du marquage,
les règles de nommage,
les noms réservés,
les limites.

La section SYNTAX contient une deuxième définition de jeu de caractères. Cette seconde définition n'est valide qu'au sein de cette section. Le principal intérêt est de rendre la définition de la syntaxe indépendante du jeu de caractères définit plus haut.

SHUNNED [CONTROLS] codes...

SHUNNED introduit une liste de codes de caractères qui ne doivent pas être utilisés dans un document de cette application, en général parce que la combinaison des bits qui le composent peuvent poser problème au système. Ces caractères peuvent cependant être utilisés dans la syntaxe, le marquage. La raison en est que le marquage s'arrête au niveau du parser. Le mot-clef CONTROLS s'il est utilisé, ajoute à cette liste tous les caractères de contrôle du système.

FUNCTION spécifie une liste de caractères ayant un sens particulier pour le parser SGML. Les caractères déclarés ici peuvent apparaître dans le document tel quels, ou bien peuvent être invoqués comme des entités : &#SPACE;.

Les trois premiers éléments, RE (record end), RS (record start) et SPACE doivent toujours être fournis. D'autres fonction peuvent être définies :

SEPCHAR : ce caractère peut être utilisé partout ou un espace est nécessaire au sens SGML. Ce mot-clef est typiquement utilisé pour définir le symbole de tabulation qui n'est pas reconnu comme tel par le norme.
MSSCHAR : ce caractère demande au parser d'ignorer le caractère qui le suit immédiatement.
MSOCHAR : ce caractère demande au parser d'ignorer les caractères suivants jusqu'à occurrence d'un caractère MSICHAR.
FUNCHAR : caractère déclaré sans comportement particulier. Peut être nommé comme tous les autres caractères définis ici dans le document.

	  
FUNCTION 	RE			13
		RS			21
		SPACE			64
		TAB	SEPCHAR		5
		SO	MSOCHAR		14
		SI	MSICHAR		15

Mots réservés, mot-clefs et casse

La sous-section NAMING permet de spécifier les caractères autorisés - en plus des caractères alphanumériques, pour tout nom SGML (identifiants génériques, nom d'attribut, nom d'entité, ...).

LCNMSTRT : Lowercase Name Start.
UCNMSTRT : Uppercase Name Start.
LCNMCHAR : Lowercase Name Characters.
UCNMCHAR : Uppercase Name Characters.

	  
NAMING	        LCNMSTRT	""
		UCNMSTRT	""
		LCNMCHAR	".-"
		UCNMCHAR	".-" 
		NAMECASE	GENERAL		YES 
				ENTITY		NO

L'ordre des chaînes de caractères définies dans LCNMCHAR et UCNMCHAR ou LCNMSTRT et UCNMSTRT doit être le même. Les caractères non affectés par la casse sont représentés de la même manière dans les deux chaînes. Il est aussi possible que des caractères apparaissent plusieurs fois afin de correspondre aux caractères de l'autre casse.

L'attribut NAMECASE indique si les caractères sont transformés en majuscule avant d'être traités. Ainsi, YES signifie que le traitement n'est pas sensible à la casse, NO le contraire. Le mot-clef GENERAL applique cette valeur à tous les éléments du document, ENTITY à ses seules entités.

	  
NAMES 	SGMLREF
		DOCTYPE 	DTD 
		ELEMENT	EL
		PCDATA	TEXT

La sous-section NAMES permet de surdéfinir les mots-clefs standards de SGML. Les nouveaux mots-clefs doivent être uniques et respecter la syntaxe concrète courante. Le mot-clef SGMLREF permet de conserver les mots-clefs standards s'ils ne sont pas surdéfinis ici.

Minimisation et autres capacités

La sous-section DELIM introduit une liste permettant de surdéfinir les symboles de séparation dans le marquage. La première colonne contient le nom du rôle, et la seconde le nouveau symbole qui lui est assigné. L'exemple donné ici présente quelques uns de ces symboles avec leur valeur standard. Tout comme les surdéfinitions de la section NAMES, celles-ci doivent obéir à quelque logique et rester homogènes avec le reste de la déclaration.

	  
DELIM 	GENERAL	   SGMLREF
		   GRPO		"("
		   GRPC		")"
		   STAGO	"<"
		   ETAGO	"</"
		   TAGC		">"
	SHORTREF   NONE

La sous-section SHORTREF n'est pas abordée ici.

La sous-section QUANTITY permet de surdéfinir quelques quantités limites, telles la longueur maximale du nom d'un élément (NAMELEN).

	  
QUANTITY	SGMLREF
		NAMELEN	32
		LITLEN	2048

Le mot-clef SGMLREF rappelle que les valeurs non modifiées ici restent égales à celles définies dans le standard.

	  
FEATURES
	MINIMIZE	DATATAG         NO
			OMITTAG   	NO
			RANK		NO
			SHORTTAG	YES  -- Only for NET --
	LINK		SIMPLE	        NO
			IMPLICIT	NO
			EXPLICIT	NO
	OTHER		CONCUR	        NO
			SUBDOC	        NO
			FORMAL	        NO

Cette section précise les les capacités facultatives de SGML utilisées dans cette application. Ces capacités sont regroupées selon trois classes : MINIMIZE, LINK et OTHER. L'exemple fourni ici est une définition des ces capacités pour XML. SHORTTAG est nécessaire pour l'utilisation des éléments vides (null end tag).

La classe MINIMIZE contient les options de minimisation ; omission de la balise de fermeture, omission du nom d'une balise ouvrante... On parle de document normalisé lorsque aucune option de minimisation n'est autorisée.

DATATAG : permet de spécifier des chaînes de caractères agissant comme balise fermante en plus de leur rôle de données textuelles dans le document.
OMITTAG : possibilité d'omettre la balise ouvrante ou la balise fermante d'un élément.
RANK : possibilité de considérer un identifiant générique comme une racine et un suffixe : un élément ne possédant pas de suffixe le déduit de l'élément identique prprécédent.
SHORTTAG : possibilité d'utiliser des balises ouvrantes vides, d'omettre la balise fermante, d'omettre les séparateurs de valeur littérale pour un attribut, ...

La classe LINK nécessiterait plus d'explication...

La classe OTHER contient les particularités qui n'entrent pas dans les autres classes :

CONCUR : permet l'utilisation de plusieurs DTD pour un seul document. Si cette capacité est validée, elle est suivie par une valeur représentant le nombre maximum de DTD alternatives (en plus de la première).
SUBDOC : supporte les entitités représentent des documents SGML complets.

SCOPE DOCUMENT | INSTANCE

La balise SCOPE spécifie si la syntaxe définie dans cette déclaration s'applique exclusivement à l'instance de document ou à la DTD également. La déclaration utilise toujours la syntaxe de référence (reference concrete syntax), ainsi que la DTD par défaut.

La section CAPACITY permet de fixer quelques valeurs qualitatives des ressources nécessaire pour le traitement d'un document de l'application concernée. Ces valeurs ne représentent pas grand chose (tant elles dépendent de l'implémentation des outils) et ne sont que très rarement utilisées en pratique.

La balise APPINFO est très peu utilisée (à ma connaissance).

Les catalogues

L'utilisation de plusieurs applications SGML différentes sur un système, l'appel à plusieurs vendeurs différents mène à deux problèmes :

l'interprétation des identifiants externes dans les déclarations d'entité doit être la même quels que soient les outils utilisés pour un document donné,
l'échange de documents SGML entre différents systèmes doit préserver cette même interprétation des identifiants externes.

Les catalogues sont une réponse à court terme pour le premier point. Un catalogue associe un identifiant public externe ou un nom d'entité à un fichier, une URL ou n'importe quel autre objet.

Chaque entrée du catalogue associe un identifiant système (FSI - Formal System Identifier) à une entité externe définie dans le document. La plupart du temps, un objet de stockage est utilisé (SOI - Storage Object Identifer). Ces derniers sont un sous-ensemble des premiers.

	  
SGMLDECL "docbook.decl"

PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1 EN//" "ISOlat1.ent"

PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	 "http://www.w3c.org/TR/xhtml11/DTD/xhtml11.dtd"

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "xhtml1-strict.dtd"

DELEGATE "-//IETF" "http://www.ietf.org/catalog.txt"

Parmi les types d'entrée d'un catalogue, on rencontre :

PUBLIC : définit un identifiant externe public (ceux introduits dans le document avec le mot-clef PUBLIC).
ENTITY : définit une entité externe.
SGMLDECL : définit l'emplacement du texte utilisé pour remplir la déclaration SGML du document.
DELEGATE : permet de déléguer à un autre catalogue la résolution d'entités externes comportant un préfixe donné.
CATALOG : spécifie un catalogue devant être consulté après le catalogue courant.

Le SDIF (SGML Document Interchange Format) adresse le deuxième point soulevé, et n'est pas développé ici.

Applications

TEI : Text Encoding Initiative

L'objectif de TEI est, depuis 1987, de représenter de manière électronique toute forme de littérature. Sa DTD est employée par de nombreuses organisations, majoritairement tournées vers la culture : religion, histoire, dictionnaires, ...

DocBook

DocBook a été conçu au départ par les éditions O'Reilly et HAL Computer Systems. Aujourd'hui, c'est le Comité Technique DocBook du Consortium OASIS qui s'en occupe. Le but de DocBook est la rédaction de livres, et son champ d'application, particulièrement bien adapté à l'informatique, a rallié à lui de nombreux utilisateurs et acteurs. La communauté du logiciel libre en particulier l'utilise énormément.

Il existe de nombreuses feuilles de styles (XSL et DSSSL) et de nombreux projets permettant de produire à partir de DocBook des documents adaptés à tous types de support : texte, Postscript, PDF, LaTeX, HTML, man, ...

Ces deux application supportent SGML et XML.

SGML et HTML

HTML est un dialecte ouvert et standardisé de SGML, comme la DTD TEI ou Docbook. Il a été conçu pour être un moyen de publication rapide et simple associé au protocole HTTP. L'association HTTP-HTML a rapidement éclipsé les autres protocoles destinés au partage de l'information comme WAIS ou Gopher.

HTML s'attache à faire simple : il ne reprend pas à son compte une des idées maitresses de SGML : la séparation du contenu et de sa forme. Ceci est toutefois corrigé autant que possible dans les dernières versions qui cherchent à réunir XML et HTML, et encouragent le recours à CSS.

SGML et XML

XML est un sous-ensemble strict de SGML. Contrairement à tous les langages vus ci-avant, il ne s'agit pas d'une application de SGML. XML est naît au W3C avec l'idée d'adapter SGML au Web afin de réutiliser la somme importante de documents existant sous le standard de 1986.

XML se veut plus simple afin d'être facilement assimilable : il n'y a pas de minimisations, ni de redéfinition de la syntaxe, aucune spécificité exotique ou complexe comme les modèles concurrents. Il n'existe donc pas de déclaration, et la DTD n'est même pas requise.

XML est aussi plus strict afin d'être facilement utilisable : le jeu de caractères considéré est Unicode, les arguments sur la syntaxe et la minimisation servent aussi ici.