![[CRDP]](/img/btn24/top_24.gif){kind=small}
![[Info]](/img/btn24/info_24.gif){kind=small}
![[Help]](/img/btn24/aide_24.gif){kind=small}
Le "Langage normalisée de balisage généralisé", la norme ISO-8879 mieux connue sous son acronyme anglais de SGML (Standard Generalized Markup Language), a, comme toute création humaine, une genèse et une histoire, si courte soit-elle. Celle-ci révèle:
"En 1969, Charles Goldfarb dirige un projet de système d'information juridique intégré. Avec Edward Mosher et Raymond Lortie, il invente le GML (Generalized Markup Language), outil permettant à des sous-systèmes d'édition, de formattage et de recherche documentaire, de partager les mêmes documents."
SGML a ainsi pris naissance dans la documentation juridique. Rien de moins surprenant, considérant la pertinence de SGML pour ce type de documentation. C'est cette pertinence qui sera d'abord mise en lumière, après un bref rappel de la signification réelle de SGML.
Mais si, pour la documentation juridique et législative plus particulièrement, SGML est l'approche incontournable, l'objectif en définitive demeure de développer une diversité d'applications informatiques utiles. L'une de celles-ci est la recherche documentaire, application informatique centrale pour la documentation juridique. Comment la fonctionnalité de la recherche documentaire se trouve grandement améliorée du fait lorsqu'elle s'exerce sur des documents conformes à SGML, c'est ce qui fera l'objet d'une démonstration approfondie.
Ces développements permettront de conclure sur les perspectives stratégiques actuelles en vue de l'implantation de systèmes SGML pour la documentation juridique québécoise.
Aux oubliettes de l'histoire documentaire est reléguée la dictature des développeurs de logiciels aux formats propriétaires, dont l'intérêt commercial étroit est de maintenir sous leur coupe et sous leurs règles les îlots documentaires de leur clientèle. Les producteurs d'information deviennent indépendants par rapport à leurs fournisseurs, désormais navrés, quand ce n'est pas paniqués, d'avoir à refaire leurs outils pour répondre à cette situation nouvelle, ou encore très humainement enclins à créer une certaine confusion intéressée en suggérant une vertu SGML soudaine, une"compatibilité" ou "convertibilité" insoupçonnées, à leurs produits propriétaires.
Une approche répandue tend à voir dans tout texte essentiellement une suite apparemment libre de caractères ou de mots d'une langue naturelle. Par exemple, un article de loi peut apparaître comme la suite des mots de cet article. Cela simplifie peut-être la tâche du rédacteur initial (ou de logiciels de traitement documentaire élémentaire). Mais pour un utilisateur externe qui voudrait réutiliser ce texte à une autre fin (par exemple produire un dictionnaire de définitions juridiques à partir des définitions parsemées dans les articles), ce texte offre peu de flexibilité, il est lourd, il ne s'adapte pas à un nouvelle sollicitation de son environnement.
Pour SGML par contre, un document est essentiellement une organisation logique de composantes textuelles, ayant entre elles des relations hiérarchiques, séquentielles ou associatives: un article de loi est une structure d'alinéas, paragraphes, sous-paragraphes, et ainsi de suite jusqu'à des éléments plus fins, souvent non visibles dans le texte, mais non moins réels, comme des termes définis et leurs définitions.
SGML sert à exprimer la richesse structurelle des documents, à identifier les composantes du texte et leurs relations. Pour cette raison, les documents SGML sont flexibles et manipulables, au gré des besoins actuels variés, mais aussi futurs et imprévisibles. On peut les qualifier d'"intelligents". Encore faut-il évidemment que des logiciels non moins intelligents (autrement dit conformes à SGML), soient capables de tirer partie fonctionnellement de cette intelligence donnée.
SGML propose que ces codes, ou balises, servent au contraire à représenter le contenu logique ou sémantique des portions de textes ainsi balisées.
C'est le balisage descriptif. Quant aux traitements à effectuer sur ces "éléments" logiques identifiés, c'est une question que l'on traite en un second temps: plus tard, en temps opportun, on associera ces éléments à des traitements spécifiques. Evidemment, ces traitements associés peuvent changer selon l'application, ou dans le temps pour un même logiciel. Mais la beauté de la chose, c'est qu'on n'aura pas à toucher au document lui-même. Conclusion: c'est toujours le même original qui sera traité et retraité sans cesse.
Un document SGML est une structure logique d'éléments qui s'emboîtent, se suivent et se référencent. Analogiquement à la table des matières, SGML statue que tout document SGML ne contient pas seulement son texte marqué de balises logiques, mais aussi la définition de la structure elle-même. SGML fournit un langage, une convention, pour précisément formaliser la définition de cette structure documentaire: c'est la "Définition de Type de Document" (DTD). La DTD fait partie intégrante de tout document SGML, elle est comme la "connaissance" ou la "conscience" que le document a de lui-même.
Physiquement, pour des raisons matérielles pratiques, il y plusieurs objets. Ainsi en est-il des documents électroniques, que l'on divise en généralement en "fichiers". Il y a donc une double structure: logique et physique, sans recoupement d'ailleurs.
Mais un "fichier" demeure un objet très dépendant de chaque système informatique; on le vérifie facilement dès que l'on veut transfèrer ses fichiers d'une plate-forme informatique une autre. Voilà une autre dépendance que des fournisseurs imposent à des documents et à des créateurs de textes, que n'intéressent nullement la syntaxe de noms de fichiers, l'organisation de répertoires ou le traitement des fins de ligne.
Contre cette dépendance, la solution de SGML réside dans les Entités, objets de stockage virtuel créés et nommés par les producteurs de textes. Ainsi, un document SGML est stocké dans une entité, ou plus probablement réparti dans plusieurs entités (une par chapitre par exemple dans le cas d'une monographie, une entité pour chaque graphique, etc.).
Evidemment, sur un ordinateur précis, il n'y a concrètement que des fichiers, ou d'autres objets de même nature, tels que des portions de mémoire ou des "enregistrements" d'une "base de données". Il faudra donc faire une équivalence entre les Entités, seules connues du créateur de textes, et ces objets concrets et particuliers à chaque système: c'est une question qui concerne le gestionnaire du système informatique, nullement les auteurs, ni les documents eux-mêmes.
Mais quand donc faut-il appliquer SGML? Aussi, SGML n'est pas une panacée universelle. Il y a des situations où SGML est incontournable, d'autres franchement inapproprié. Les critères de l'opportunité d'une application SGML sont les suivants:
- Besoin d'échanger les mêmes documents entre intervenants multiples
- Complexité des documents et besoin de normalisation
- Exigence d'un contrôle de qualité et d'intégrité élevé des documents, besoin de validations
- Retraitements multiples des mêmes textes
- Réutilisation de textes ou portions de textes pour de nouveaux produits documentaires ou produits dérivés
- Durée de vie élevée des documents et besoin de conservation à long terme
- Saine gestion, contrôle des coûts et des délais, libre choix des fournisseurs
- Capacité d'adaptation technologique
Sur la base de ces critères, on excluera par exemple les documents de publicité où l'unicité, la volatilité et la fantaisie sont au contraire des atouts. Il en ressort toutefois que la documentation juridique, et les textes de loi plus particulièrement, présentent les caractéristiques typiques d'une application SGML:
- Echange: circulation des mêmes textes de loi entre ministères-rédacteurs, comité de législation, Assemblée nationale, Commission de refonte, organismes d'application, diffuseur public, éditeurs privés, etc.
- Complexité: grande variété des types de documents (loi, règlements, refontes, jurisprudence, monographies et articles de doctrine, manuels d'interprétation et d'application de lois, etc.), avec renvois multiples entre eux (entre articles, vers et depuis la jurisprudence, etc.)
- Qualité: aucune erreur permise dans le texte de loi officiel
- Retraitements: variété des produits documentaires (projets de lois, Gazette officielle, Lois refondues, tirés à part, banques en lignes, etc.)
- Réutilisation: activité de refonte à partir des amendements, Lois annotées, manuels d'application, publications commerciales, etc.)
- Longévité: intérêt permanent des versions historiques de chaque article
- Saine gestion: obligation normale du secteur public
- Adaptation technologique: diffusion sur nouveaux supports (DOC, Internet).
En somme, toutes ces caractéristiques de la documentation législative et juridique d'être des documents complexes, dynamiques, échangés, de haute qualité, retraités, réutilisés, de longue durée, et de nature publique, appellent et justifient des solutions documentaires basées sur SGML. Autrement dit, le bon sens dicte la nécessité, l'inévitabilité de développer des "applications SGML" juridiques, c'est-à-dire un ensemble de DTDs (de loi, de jurisprudence, de manuels d'application, etc.), et de conventions d'applications pour chaque type de document.
- système de rédaction et refonte législative, y compris la génération des imprimés officiels, à l'intention des ministères-auteurs, du législateur et du ministère de la Justice
- systèmes d'application de lois assistées par ordinateur (ALAO) à l'intention des organismes d'application des lois
- systèmes de recherche documentaire pour les éditeurs publics et privés de publications électroniques juridiques
Chaque système identifié pourrait faire l'objet d'une analyse approfondie.
Dans le contexte de la présente communication, les caractéristiques d'un système SGML de recherche documentaire juridique seront détaillées.
Pour démontrer la supériorité de la recherche documentaire basée sur des documents SGML, un détour préalable est nécessaire pour expliquer ce qu'est en substance la recherche documentaire, et dissiper ainsi plusieurs confusions à ce sujet. Deux sous-questions doivent être clarifiées, qui seront abordées successivement:
- qu'est-ce que la documentation ?
- que signifie rechercher ?
La physique contemporaire est une source précieuse d'inspiration pour aider à comprendre la réalité documentaire. Une fructueuse analogie peut en effet être faite entre l'organisation de l'Univers physique et celle de la documentation. La science physique décrit ainsi la structure de l'Univers:
"D'atomes en molécules, d'étoiles en galaxies, d'amas en super-amas, notre univers est construit sur un mode hiérarchique. Les êtres semblables se groupent pour former de nouveaux êtres, à un niveau supérieur. Cette hiérarchie s'étend de l'infiniment petit à l'infiniment grand." Hubert Reeves (Patience dans l'azur).
Schématiquement les couches de la structure hiérarchique de l'Univers sont donc les suivantes, de la plus englobante à la plus atomistique:
- Super-amas et Amas
- Galaxies
- Systèmes planétaires
- Corps célestes (étoiles, planètes, ...)
- Molécules
- Atomes
- Particules élémentaires (protons, neutrons, électrons, neutrinos)
- Quarks
Le lecteur voudra bien consulter le livre mentionnée de Hubert Reeves pour une compréhension plus approfondie de ce sujet.
Analogiquement, on pourrait décrire la structure, tout aussi hiérarchique, d'un univers de documents, de la façon suivante:
Objets documentaires Définition
Docuthèques Collections de Docubases
Docubases Bases documentaires, i.e.collections
d'unités documentaires
Hyperdocuments Réseaux d'unités documentaires
Unités documentaires Unités d'information consommées
Modèles de contenu Déclarations d'éléments SGML
Eléments textuels Éléments et pseudo-éléments SGML
terminaux, valeurs d'attributs SGML
Mots, syntagmes Unités signifiantes du langage naturel
Lettres, pixels Unités non signifiantes du texte
J'appelle Docuvers cette taxonomie des objets documentaires. Ce schéma, on le voit, est d'un grand parallélisme avec la structure de l'univers physique.
Super-amas et Amas Docuthèques Galaxies Docubases Systèmes planétaires Hyperdocuments Corps célestes Unités documentaires Molécules Modèles de contenu Atomes Éléments Particules élémentaires Mots, syntagmes Quarks Lettres, pixels
Revenant à la documentation juridique, on pourrait ainsi illustrer le cas d'un Docuvers législatif (simplifié en omettant les niveaux inférieurs du Docuvers):
Objet documentaire Exemple législatif
Docuthèque Ensemble des documents d'appli-cation
d'une loi (codification
admi-nistrative, banque de
jurisprudence, répertoire de pratiques
opéra-tionnelles et de décisions
interpré-tatives, etc.)
Docubase La banque des lois refondues du Québec
Hyperdocument Une loi complète
Unité documentaire Un article d'une loi
Elément textuel Un commentaire d'un juriste sur un
article
D'un point de vue formel et syntaxique, tout objet documentaire peut être décrit en termes SGML: on peut ainsi très bien faire la DTD d'un article de loi seul, ou d'une loi entière, ou d'une banque de loi, ou encore d'une collection de documents juridiques divers. On aura alors autant de "types de document". Le Docuvers quant à lui est un outil pour classifier les objets documentaires formellement définis avec SGML. Or ce concept de Docuvers est nécessaire pour bien comprendre le processus de la recherche documentaire.
Le point important ici est: tous les objets documentaires ainsi balayés sont classifiées logiquement selon une table de classification. A noter que dans l'exemple, la classification sert aussi au classement physique (rangement des livres sur les rayons).
Bouquiner, c'est donc suivre la classification hiérarchique donnée d'un ensemble d'unités documentaires. Le même processus peut aussi se faire électroniquement, à condition qu'un travail préalable de classification ait été fait sur le corpus de documents. Cette classification est faite au moyen d'une table de classification, qui se présente comme une hiérarchie de rubriques de classification; à chaque niveau de la table, les rubriques sont dans un ordre séquentiel donné.
Bouquiner électroniquemen et revient alors à afficher cette table de classification, et, en suivant la hiérarchie et la séquentialité des rubriques, à y sélectionner successivement certaines de ces rubriques, sous-rubriques, sous-sous-rubriques, et ainsi de suite, possiblement jusqu'au terme de la hiérarchie, qui se présente comme une liste des unités documentaires classifiées. L'usager peut s'arrêter à tout niveau de la table, et demander alors la liste des unités documentaires classifiées sous la rubrique de classification sélectionnée. Plus l'usager s'arrête vite, plus il en prend large, plus la liste d'unités documentaires à examiner séquentiellement sera longue.
Le bouquinage électronique a un avantage évident par rapport au bouquinage physique: l'emplacement physique d'une unité documentaire ne contraint pas le bouquinage. Une même unité, même physiquement stockée, peut en effet se retrouver virtuellement à plus d'une place, c'est-à-dire sous différentes rubriques de classification, appartenant à différentes tables de classification.
Le bouquinage est un mode nécessaire de la recherche documentaire. C'est le mode approprié lorsque:
- on veut prendre connaissance de l'ensemble du contenu d'un document (que ce "document" soit une bibliothèque entière ou un livre donné);
- on ne recherche pas une information précise, mais plutôt une vue d'ensemble d'un sujet, une introduction à un nouveau domaine;
- on recherche de nouvelles idées, on veut prendre la mesure de son ignorance et découvrir la simple existence de terres inconnues.
Le bouquinage constitue souvent la porte d'entrée la plus accueillante à un univers documentaire, surtout lorsque l'on s'y aventure pour la première fois. Il peut être la bouée de sauvetage toujours secourable si jamais on en vient à se sentir perdu dans un docuvers, à la suite par exemple d'un butinage trop audacieux.
Le butinage correspond à la recherche en mode hypertexte. Alors que le bouquinage part d'un outil de recherche documentaire particulier (la table de classification), le butinage part lui d'un texte affiché. Dans ce texte, des indicateurs (icônes ou rehaussements) marquent l'existence de "liens". Ceux-ci ont une fonction analogue aux sous-rubriques de classification (ou aux entrées d'index: voir ci-après). En les sélectionnant, le système localise un autre texte et le présente. Entre les deux textes, celui d'origine et celui de destination du lien, il y a une relation sémantique associative quelconque. Ils appartiennent à un même groupe de textes ayant entre eux des liaisons croisées intenses.
Le butinage présente l'intérêt de satisfaire une tendance particulière de l'esprit humain, celle de faire des associations spontanées lorsqu'il est stimulé par une information ou une idée.
Le repérage textuel se fait généralement à partir d'index de mots simples. Ces mots sont normalement extraits tels quels du texte recherché; éventuellement, ils sont soumis à des traitements linguistiques ou statistiques pointus. Même si un index des mots existe usuellement pour cette recherche, sa présentation à l'usager en recherche n'est ni fréquente, ni d'ailleurs très utile. Pour repérer dans le texte intégral, l'utilisateur dactylographie sa question dans une, parfois plusieurs, cases vides, qui peuvent évoquer des formulaires de saisie de données. Le texte de la question tapée peut être en langage naturel, et/ou dans un langage de requête formalisé.
Des mots de la question peuvent être qualifiés par leur provenance dans la structure originelle du document, en supposant évidemment qu'une certaine structure existe. Dans les systèmes pré-SGML, cette structure, exprimée dans un format propriétaire, est généralement plate: c'est une liste séquentielle de "zones" ou "champs". Si le document est SGML, la structure est fort probablement hiérarchique: la qualification des mots recherchés se fait alors par leur élément SGML de provenance.
Une telle qualification a pour but limiter les résultats du repérage. Cette limitation repose toutefois sur une hypothèse contestable, à savoir que les chercheurs sont censés connaître, ou même intéressés à connaître, la structure utilisée au moment de la création du document. Or cette structure (ou DTD dans un contexte SGML), peut être relativement complexe, en raison de la prise en compte de plusieurs objectifs concurrents (gestion de la production, composition, ...), n'ayant rien à voir avec le repérage documentaire. De plus, en SGML, la structure des documents est hiérarchique: il en résulte que le seul identificateur générique d'un élément est insuffisant pour qualifier la provenance d'un mot, le contexte hiérarchique de l'élément étant aussi requis: cela ne fait qu'ajouter à la difficulté d'un repérage textuel qualifié avec SGML.
Contrairement au repérage textuel, le repérage par index se fait plus souvent par expressions multi-termes. Celles-ci peuvent être extraites simplement du contenu textuel d'un ou plusieurs éléments spécifiés. Mieux, chaque entrée d'index peut être construite à partir de plusieurs éléments groupés, ordonnés et connectés. De tels index générés, véritables produits dérivés de l'instance originelle, sont ensuite présentés à l'usager pour butinage à l'aide de fonctions de positionnement, de filtre et de liaison. Cette présentation des index fournit une aide précieuse pour alléger le fardeau de l'usager quant à la formulation sa question. Au lieu de se trouver devant une "page blanche" ou une "case vide" pour poser sa question, le chercheur, (en harmonie d'ailleurs avec les interfaces graphiques usuelles), interroge en pointant, sélectionnant et combinant des entrées de divers index.
Le tableau suivant permet d'établir son plan de voyage: il montre comment les trois modes de recherche peuvent s'exercer à chaque niveau de la structure d'un Docuvers (simplifié). Chaque cellule du tableau indique sommairement un moyen de transport spécifique (correspondant ultimement à un ensemble de fonctionnalités attendues d'un logiciel de recherche documentaire).
Bouquiner Butiner Repérer
Docuthèques Classification des Liens inter-bases Repérage
docubases multi-bases
Docubases Table des matières Liens intra-bases Index Texte
intégral
Hyperdocuments Table des matières Liens hypertextes Repérage dans
sous-bases
Unités Canevas Liens intra-UD Repérage secondaire
Documentaires
Pour reprendre la comparaison des voyages dans l'univers, tout individu, pour se rendre d'un endroit à un autre, choisira le mode de transport qui convient le mieux, ou une succession appropriée de modes de transport. De même, selon les objectifs visés, l'un ou l'autre mode de recherche sera le plus approprié dans les circonstances, ou encore une combinaison de ces modes. Il n'empêche que chaque mode de recherche, comme chaque mode de transport, a ses caractérisques particulières. En définitive, tout comme le transport, la recherche documentaire est une triade.
Une triade qui forme un tout. Chaque méthode de recherche a ses inconvénients. Par exemple, une faiblesse connue du butinage hypertexte est l'état de perdition que ce mode génère inévitablement. Sauf si le butinage se fait dans un hyperdocument relativement restreint, il s'avère aussi particulièrement inefficace pour le repérage direct et rapide, les critères de recherche étant limités aux liens rencontrés au hasard du butinage.
Or les avantages de chaque mode de recherche compensent les inconvénients des autres modes. Ainsi, le bouquinage fournit une sorte de carte géographique pour se situer dans le docuvers quand le butinage nous a entraîné dans des terres inconnues. Le repérage coupe court à des butinages interminables et infructueux quand on sait ce que l'on cherche.
Pour la constitution des rubriques des tables de classification, celles-ci peuvent évidemment être extraites complètement d'un élément en contexte spécifié. Les rubriques peuvent aussi être construites à partir d'éléments sélectionnés, ordonnés et connectés: par exemple, les rubriques d'une table de matières d'une loi proviendront normalement du numéro de la subdivision (Livre, Chapitre, Section, etc.), suivi du titre de la subdivision, les deux informations pouvant être dans des éléments différents.
Le repérage textuel limité à un contexte spécifique peut être aussi beaucoup plus raffiné que dans le cas des bases "plates" composées de "zones" ou "champs" à un même niveau. Le contexte est en effet ici hiérarchique et le simple nom de l'élément ne peut plus suffire à qualifier le contexte de mots recherchés. Limiter une requête aux mots du "titre" n'a pas de sens alors qu'existe un variété de titre, dépendant du contexte hiérarchique (titres de chapitre, de section, de tableau, de figure, cité dans le texte, etc.), d'autant plus qu'un bon style de rédaction de DTD invite précisément à faire l'économie des noms d'éléments.
Enfin, des fonctions de traitement linguistique, visant à surmonter, à des fins de repérage textuel, les problèmes de morphologie, polysémie, ou synonymie, deviennent nécessairement plus performantes dans un document SGML grâce à la qualification fine du contexte où ces traitements peuvent désormais s'exécuter.
De plus, sur la base des liens de parenté entre éléments, il est possible de générer des index hiérarchiques à plusieurs niveaux, l'entrée de chaque niveau pouvant être elle-même construite. Par exemple, un index des auteurs par affiliation peut être généré, même si les affiliations peuvent être multiples pour un même auteur, et si la hiérarchie est inverse dans le document traité.
On remarque que ces interrogations sont formulées sans considération aucune quant au contenu textuel des éléments recherchés. Ce qui est demandé, ce sont des objets textuels, plus spécifiquement des constructions SGML, repérées sur la base de la position de ces objets dans la structure documentaire. SGML permet de telles requêtes, formulables d'ailleurs dans un langage de requête normalisé (SDQL: Standard Document Query Language). L'intérêt de telles requêtes est considérable pour quantité de fonctions documentaires.
Dans un contexte SGML, c'est ce qu'il faut entendre par repérage structuré. Il convient de ne pas confondre ce repérage DE structure avec la fonction très pointue de qualification des mots recherchés dans le repérage textuel (qui est plutôt une repérage DANS la structure); ni non plus avec la génération d'index butinables dans le repérage par index, qui est un repérage GRACE A la structure.
La flexibilité des documents SGML peut aussi être mise à profit au moment de la présentation des résultats de recherche. La présentation comporte deux aspects. Le premier (très souvent le seul dans plusieurs systèmes) concerne la mise en forme typographique à l'écran. Elle se fait généralement en fonction de "feuilles de styles" associant des éléments en contexte et les caractéristiques typographiques usuelles. Certes, c'est là une méthode usuelle de traitement de documents SGML, qui en révèle d'ailleurs un avantage distinctif: la possibilité de varier à l'infini le formatage puisque le document SGML est lui-même neutre et exempt de toute instruction procédurielle.
Cependant une présentation exploitant la richesse du balisage SGML permet en plus une transformation prélalable du texte SGML avant son formatage et sa restitution. La transformation est le processus permettant de sélectionnner, réordonner, grouper et emboîter les composantes du texte à afficher. En somme, la structure logique de présentation du document peut être complètement différente de celle du document original. Le texte présenté est alors construit à partir du texte repéré, c'est une vue nouvelle, en termes non seulement de formatage, mais aussi de contenu et de structure. Evidemment, ce processus suppose encore une fois un document "intelligent", dont bien sûr une application non moins intelligente saura exploiter la connaissance.
Une flexibilité supplémentaire que procure SGML en affichage est la possibilité de restitution intégrale du contexte. Toute unité documentaire présentée correspond à un élément de la structure du document. Mais cet élément a toujours une généalogie connaissable, une descendance bien sûr, mais aussi une ascendance. Rien n'empêche, si besoin est, de signaler ces ancêtres quand on présente la progéniture.
- table des matières de telle loi ?
- structure d'une décision de jurisprudence ?
- article précédent ou suivant dans la loi ?
- version antérieure de cet article ?
- texte de cet article référencé ?
- commentaire de Maître Beaudouin sur cet article ?
- version anglaise de l'article ?
- articles traitant du concept d'"habeas corpus"
- articles sur les inspecteurs de la voirie intéressant les municipalités ?
- décisions interprétant l'article 245 du code civil ?
- articles sur les congédiements en date du 12 juillet 1990 ?
- afficher avec de plus grands caractères à l'écran
- passages modifiés dans la nouvelle version d'article
L'application de SGML à la documentation juridique est un fait inévitable. Les raisons sont trop nombreuses: techniques (caractéristiques documentaires, flexibilité informatique), professionnelles (recherche documentaire plus performante), sociales (préservation à long terme du patrimoine démocratique), politiques (réduction du déficit budgétaire).
Par ailleurs, il n'y a pas d'objection valable. Plusieurs logiciels conformes à SGML existent sur le marché, pour l'ensemble des fonctions de la chaîne éditoriale, et leur nombre ne cesse de croître. L'expertise SGML existe et est disponible sous forme de cours de formation, services de consultation, de publications et conférences. Une DTD des lois québécoises existe: elle a été écrite à l'occasion de mandats divers par la société DOCUMENSA, qui a décidé de la mettre dans le domaine public, d'agir à titre de gardien de cette DTD et de la faire évoluer au rythme des améliorations que suscitera son utilisation.
La seule question véritable qui se pose est comment procéder, quelle stratégie suivre, dès aujourd'hui. Voici, en cinq points, les éléments d'une stratégie possible:
1) Se former à SGML: les gestionnaires de systèmes documentaires doivent se familiariser avec SGML, des cours sont disponibles.
2) Lancer un projet mobilisateur: un système qui s'impose de soi dans tout Etat est un système de rédaction et refonte législative; le premier pas est de mener une étude de faisabilité de cette application, concluant sur les premiers pas concrets réalisables dans cette direction.
3) Démontrer les bénéfices de SGML: un disque optique des Lois refondues du Québec démontrerait rapidement les bénéfices de la recherche documentaire basée sur SGML;
4) Paver l'inforoute francophone en SGML: parions que pour l'information professionnelle, la diffusion sur le "WEB", maintenant possible, de documents SGML (plutôt que HTML) est la voie de l'avenir; commençons au moins par essayer sur des "WEB" internes.
Après tout cela, il ne reste que le courage de décider.