Projet pilote d'échange d'information sur formulaires électroniques normalisés

Rapport sommaire
Préparé pour :
Groupe de travail sur les normes des documents électroniques (GTNDE)
Secrétariat du Conseil du Trésor
Gouvernement du Canada

Préparé par :
Larry Osipenko
InfoDesign Corporation
31 mars 1996

Révisé par le GTNDE (15 novembre 1996)
Mis à jour le 27 novembre 1996

Table des matières

Annexe A : DTD de formulaire électronique 39

Annexe B : Formulaire Convention de services 45

Annexe C : Formulaire Demande de traduction 51

Annexe D : PARTICIPANTS - Projet pilote de normalisation de l'interface des formulaires électroniques 65

Sommaire

Ce projet s'inscrit dans le cadre de l'effort permanent des responsables du programme des normes du gouvernement pour définir et mettre en valeur des documents électroniques normalisés respectueux des politiques fédérales de gestion de l'information et des technologies de l'information.

Ce projet visait à définir et à mettre à l'essai une norme d'interface en vue de l'échange de données sur les formulaires électroniques entre les applications de formulaires électroniques de divers fournisseurs. Vu que de nombreux formulaires électroniques sont actuellement utilisés au sein du gouvernement fédéral, il est nécessaire d'échanger des données propres à chacun pour en poursuivre l'implantation dans un contexte de «systèmes ouverts». Cette démarche permettra d'éviter la création de «zones protégées» et réduira le risque de recours à un fournisseur unique de formulaires électroniques de la part du gouvernement.

Comme le précise le présent rapport, l'équipe chargée du projet a conçu et mis à l'essai efficacement une interface normalisée en vue de l'échange de données des formulaires électroniques entre les applications de divers fournisseurs.

Le rapport porte sur cinq questions distinctes :

1. la normalisation de la structure et du contenu des formulaires électroniques;
2. l'appui du traitement des formulaires électroniques;
3. l'échange de données sur les formulaires électroniques et de feuilles de style;
4. un mécanisme de soutien de la normalisation et de l'échange de formulaires électroniques;
5. l'archivage des données sur les formulaires.

Chacune de ces questions fait l'objet d'une discussion assez détaillée. Les conclusions tirées des travaux exécutés dans le cadre de ce projet, de même qu'une section renfermant des recommandations de mise en œuvre figurent à la fin du rapport. La section des recommandations précise les suggestions du Groupe de travail sur les normes des documents électroniques que le gouvernement fédéral devrait appliquer en vue de l'implantation des formulaires électroniques normalisés dans l'ensemble de ses services.

1. Contexte

Le présent rapport, préparé par InfoDesign Corporation pour le compte du Secrétariat du Conseil du Trésor, passe en revue les objectifs, les résultats et les recommandations d'un projet pilote de normalisation des formulaires électroniques utilisés pour échanger de l'information (ci-après désigné projet pilote d'interface des formulaires électroniques) exécuté par ses participants en collaboration avec le Groupe de travail sur les normes des documents électroniques.

Le projet pilote d'interface des formulaires électroniques représente le suivi de la mise en œuvre d'un prototype de formulaire électronique qui a permis de démontrer que :

• des normes internationales pourraient servir à décrire la structure et le contenu (c'est-à-dire préparer une définition de type de document, ou DTD) pour chaque type de formulaire électronique;
• l'information contenue dans les formulaires électroniques pourrait être déterminée au moyen de conventions de marquage standard appliquées aux documents électroniques (p. ex. le langage normalisé de balisage généralisé (Standard Generalized Markup Language, ou SGML));
• les applications SGML de divers fournisseurs pourraient communiquer par réseaux locaux et grands réseaux de manière à échanger des données sur les formulaires électroniques.

Le projet pilote de normalisation de l'interface des formulaires électroniques a réuni des participants des secteurs public et privé qui représentent plusieurs ministères fédéraux, les Services gouvernementaux de télécommunications et d'informatique (SGTI), des spécialistes du SGML et des fournisseurs de logiciels de formulaires électroniques (la liste des participants figure à l'annexe D). L'équipe chargée du projet a exécuté le projet pilote d'interface pour :

• prouver que les applications actuelles de formulaires électroniques peuvent être améliorées pour échanger les balises de données dans le SGML;
• prouver que les étiquettes SGML qui décrivent les données des formulaires électroniques pourraient être échangées par les systèmes ministériels de courrier électronique qui sont interreliés au moyen du Réseau électronique gouvernemental (REG);
• déterminer les questions découlant de l'élaboration et de la mise à l'essai d'un prototype d'interface pour formulaires électroniques et présenter des recommandations à ce sujet;
• élaborer une stratégie pour la mise en oeuvre de la description normalisée des formulaires et de l'échange de données des formulaires électroniques au sein du gouvernement fédéral.

2. Définitions

Applications de type extensions - application exécutée par le navigateur Web lorsqu'un flux de données reçues ne respecte pas le HTML ou ne peut être traité par le navigateur. L'en-tête du flux de données détermine le type de données de la transmission. Selon le genre de données reçues, le navigateur appelle l'application de type extensions pertinente à l'ordinateur client.

Application SGML - une DTD ou ensemble de DTD assorties de lignes directrices énonçant le mode d'application des DTD pour une certaine catégorie de documents. Par exemple, HTML est une application SGML, comme CALS (initiative d'échange électronique militaire) et J2008 (pour les documents techniques dans le domaine de l'automobile), entre autres. À cette fin, la DTD SGML et le jeu de lignes directrices qui définissent l'échange de formulaires électroniques sont considérés comme une application SGML.

Comité du World Wide Web (Comité W3) - comité international ayant pour mandat de définir les normes appliquées dans le World Wide Web (W3). Outre d'autres normes, le Comité W3 définit et tient à jour le HTML.

Conception de formulaires électroniques (application) - l'application de conception de formulaires électroniques permet à l'utilisateur de dessiner un formulaire à l'écran et d'en définir les divers champs. La définition du formulaire comprend la liste des champs applicables, ainsi que leurs définitions et leurs attributs, notamment les instructions de masquage de l'information, les contraintes de sécurité, les spécifications relatives aux types de données, et la longueur fixe ou maximale des champs. Les caractéristiques d'affichage, qui contrôlent la présentation globale sur le formulaire, sont intégrées à une composante de feuille de style. Cette composante renferme des attributs qui précisent la couleur de fond du formulaire, la place des lignes horizontales et verticales, la taille des cases et leur style, les titres de champs, l'ombrage, les polices (taille et point).

Cryptage - méthode de codage d'un document qui en réserve la lecture aux utilisateurs ou programmes dotés de la clé de décryptage (décodage) pertinente.

Données du formulaire - le contenu véritable d'un formulaire électronique habituellement saisi à l'aide d'une application de préparation de formulaire électronique.

DSSSL - Document Style Semantics and Specification Language (Sémantique de présentation de documents et langage de spécification) - composante facultative d'une application SGML qui définit une méthode de formatage et de traitement des documents SGML propre à un fournisseur ou à une application. Réduite à sa plus simple expression, une spécification DSSSL ressemble à une feuille de style utilisée par des logiciels de traitement de texte courants comme MS-Word et WordPerfect de Corel.

DSSSL Lite - sous-ensemble de DSSSL qui définit les renseignements sur les feuilles de style propres à un fournisseur et servant à visualiser en direct et à imprimer des documents SGML.

DTD (Définition type de document) - composante d'une application SGML qui détermine les règles régissant la structure et le contenu de documents appartenant à un «type» ou à une catégorie de documents. Ce fichier de règles précise les éléments et attributs valables qui peuvent ou doivent être intégrés à ce «type» de document. Il comprend également des renseignements concernant l'ordre et la combinaison de ces éléments.

DTD générique - définition type de document qui n'utilise pas de noms d'élément ou d'attribut à contenu spécifique. Pour les formulaires électroniques, une DTD générique définit le jeu d'éléments et d'attributs génériques qui peuvent être utilisés pour nommer et définir les champs de saisie de tous les formulaires électroniques. Plus particulièrement, elle définit un élément unique nommé «intrant» auquel est rattachée une série d'attributs définis par l'utilisateur pour préciser le nom du champ de saisie, de même que des attributs, comme la taille, les renseignements de masquage, la sécurité et le type de données. Dans ce cas, l'«utilisateur» est le concepteur des formulaires.

Échange de feuilles de style - méthode d'échange de données sur le formatage et le style aux fins de la présentation et de l'impression de formulaires électroniques. Toutes les applications de formulaire électronique utilisent actuellement leurs propres champs de définition des feuilles de style. Pour échanger ces données, il faut recourir à un langage et à une syntaxe convenus propres à un fournisseur et qui peut servir à définir et à échanger les données (par exemple, DSSSL).

Feuille de style - en général, spécification de formatage définie par une application de conception de formulaire électronique. La feuille de style définit la disposition ou la version «vierge» d'un formulaire dans laquelle le contenu d'un champ particulier s'affiche lorsqu'un formulaire est demandé ou imprimé. La feuille de style comprend des renseignements, comme la largeur et la couleur des lignes horizontales et verticales, les cases, le libellé et l'ombrage, qui ont trait au contenu de chaque champ.

HTML - Hypertext Markup Language (langage de balisage hypertexte) - langage de balisage de document destiné au Web. HTML est une application de SGML qui définit une série d'étiquettes que les navigateurs Web, comme Mosaic et Netscape, peuvent formater. Il comprend également un mécanisme universel de liaison avec les hyperliens, d'un endroit à l'autre dans un même document, à l'aide d'un serveur Web se trouvant quelque part dans le monde.

Instance (formulaire électronique) - dans le cas d'un formulaire électronique, document renfermant les données saisies par l'utilisateur de l'application de préparation du formulaire électronique. Il sert habituellement dans une «instance», c'est-à-dire que le document est conforme à une certaine définition type de document (DTD).

Instance (modèle) - comme le recommande le présent document, tous les formulaires électroniques sont définis par une DTD générique unique. Des formulaires électroniques particuliers, comme la «Demande de traduction» et la «Convention de services» seraient ensuite définis à l'aide de modèles conformes à la DTD générique. Ces modèles (ou formulaires «vierges») sont véritablement des instances de la DTD générique et ils définissent tous les champs de saisie (comme le nom du demandeur, le code de la direction et le code postal) utilisés sur le formulaire électronique particulier, de même que la définition des champs portant, entre autres, sur le nom du champ et sa taille, les renseignements de masquage, la sécurité et le type de données . La section 5.2 DTD unique pour l'ensemble des formulaires électroniques ou DTD pour chaque formulaire renferme une explication de la différence entre le «modèle» d'une DTD de formulaire électronique générique unique et une DTD à contenu particulier pour chaque type de formule.

Instructions de traitement - balisage spécial admis dans tous les documents SGML. Les instructions de traitement sont intégrées aux documents utilisés pour demander à l'ordinateur d'exécuter des fonctions spéciales. Pendant le traitement du document, les instructions, comme l'emplacement du curseur, ne sont habituellement pas considérées comme faisant partie des données saisies par l'utilisateur.

Interface de passerelle commune (Common Gateway Interface, CGI) - interface standard des serveurs Web (World Wide Web) pour lancer des programmes permettant d'exécuter une certaine fonction.

Modèle - essentiellement un formulaire vierge qui définit tous les champs de saisie dudit formulaire. Le modèle est ensuite utilisé comme base d'acceptation et de validation des données saisies par les utilisateurs.

Préparation de formulaire électronique (application) - l'application de préparation de formulaire permet à l'utilisateur de saisir l'information (données du formulaire) d'un formulaire donné. Cette application utilise les définitions établies par l'application de conception de formulaire électronique pour afficher et formater à l'écran les champs de saisie voulus. En outre, elle se charge de fonctions telles la sécurité et l'intégrité des données à chaque champ saisi.

SGML - Standard Generalized Markup Language (langage normalisé de balisage généralisé) (ISO 8879) - Approuvée par l'ISO (Organisation internationale de normalisation) en 1986, cette norme internationale définit un langage et une syntaxe permettant de préciser des types de documents. Réduite à sa plus simple expression, elle permet de définir et de valider une série d'étiquettes pour un certain genre de documents (voir «DTD»). Appliquée aux formulaires électroniques, le SGML peut servir à définir les règles et la syntaxe de présentation du formulaire, les modèles et les instances à échanger entre les applications et les utilisateurs.

SGMLOpen - consortium composé principalement de fournisseurs de logiciels et qui a pour but d'élaborer, de tenir à jour et de faire respecter des lignes directrices utilisées pour mettre en oeuvre des logiciels fondés sur le SGML. SGMLOpen fait également la promotion du SGML auprès d'organismes commerciaux généraux.

Signatures numériques - méthode d'identification et de validation attestant qu'un document a été «signé» par la personne désignée. Cette fonction est habituellement activée au moyen d'algorithmes cryptographiques.

Type de document - série ou «catégorie» de documents possédant des structures et un contenu communs. Les livres, les lois et règlements, les manuels techniques, les revues, les articles, etc., représentent des types de documents uniques en raison de l'unicité de leurs caractéristiques.

Type de données - type de renseignements pouvant être saisi dans un champ d'un formulaire (p. ex. la date, un nombre, des caractères).

Type MIME - MIME est un protocole de codage standard popularisé par l'Internet pour les pièces jointes aux messages électroniques. Le type MIME est un champ du message électronique qui détermine le genre (MS-Word, Excel, WordPerfect, etc.) de document codé et joint. Bon nombre de systèmes de courrier électronique se fondent sur le type MIME pour décoder le document et lancer l'application pertinente afin de visualiser le document. Les types MIME sont enregistrés et publiés par les organismes centraux de normalisation.

3. Les possibilités

L'utilisation des formulaires électroniques est de plus en plus répandue au sein du gouvernement du Canada. Pour répondre à ses propres besoins, chaque ministère adopte des solutions fondées sur ces formulaires, solutions que des milliers de fonctionnaires fédéraux utilisent eux-mêmes tous les jours.

À ce jour, les applications de formulaire électronique dans les ministères se sont avérées rentables, car elles permettent de réduire le recours à la version papier et d'éliminer les problèmes d'efficience inhérents à leurs mécanismes de manutention et de distribution (une économie d'environ 35 $ par instance, selon les estimations de l'industrie). On prévoit que la croissance exponentielle de l'utilisation de ces formulaires se poursuivra pendant de nombreuses années, le gouvernement du Canada s'efforçant de travailler plus intelligemment, de rationaliser ses flux d'information et d'en faire plus avec moins.

Actuellement, le gouvernement utilise des milliers de formulaires papier dont seulement 10 à 20 p. 100 existent déjà sur support électronique, mais sont limités aux projets de certains ministères qui ont opté pour des logiciels de formulaires électroniques propres à des fournisseurs particuliers.

Les possibilités suivantes s'offrent au gouvernement fédéral :

· réduire le nombre de formulaires en rationalisant les données recueillies et en supprimant les formulaires inutiles;

· offrir les formulaires sur support électronique afin de réduire la paperasserie et de les préparer, de les acheminer et de les gérer plus rapidement et plus efficacement;

· assurer, de façon efficace et sûre, l'échange, le traitement et l'archivage de l'information fournie par des formulaires à partir d'opérations commerciales et administratives électroniques exécutées par le gouvernement fédéral et le secteur privé.

4. Les défis

Même si le gouvernement exécute certaines initiatives indépendantes pour réduire la paperasserie et faciliter le commerce électronique en général, le présent rapport se limite à un objectif plus restreint, c'est-à-dire prouver que le gouvernement peut échanger, traiter et archiver, de façon sûre et efficace, l'information issue des formulaires électroniques.

Pour atteindre cet objectif, plusieurs obstacles techniques doivent être discutés et éliminés. Entre autres, l'information issue des formulaires électroniques doit satisfaire aux exigences suivantes :

• échange sûr entre plusieurs applications variées de courrier électronique, de passerelles et de réseaux;
• échange efficace entre les différentes applications de formulaires électroniques;
• traitement uniforme grâce à l'utilisation des fonctions de signature électronique, de validation des données et de sécurité offertes par différentes applications de formulaires électroniques;
• archivage permettant une restitution intégrale par les applications de formulaires électroniques futures.

Dans un réseau d'utilisateurs homogène où tous travaillent avec une version identique de la même application de formulaires électroniques, ces obstacles sont pour la plupart inexistants ou ont une faible incidence. Bon nombre des applications actuellement offertes par les fournisseurs assurent la sécurité des échanges et un traitement uniforme entre les installations en réseaux de leurs produits grâce à des outils qui leur sont propres. Toutefois, dans une organisation de l'ampleur de celle du gouvernement canadien, il n'est pas possible (ni nécessairement avantageux) d'utiliser une seule application de formulaires électroniques à l'échelle de l'organisation et dans les entreprises privées qui effectuent des opérations électroniques avec le gouvernement fédéral.

Même s'il était possible de ne mettre en oeuvre qu'une application, l'archivage demeurerait problématique puisque les versions futures des logiciels d'un fournisseur pourraient ne pas être en mesure de traiter les données créées avec les versions antérieures. C'est pourquoi, tant que le gouvernement n'aura pas éliminé les obstacles susmentionnés, il ne pourra assurer l'échange efficace et sûr des données des formulaires électroniques à l'intérieur des ministères et entre eux et avec le secteur commercial et, par conséquent, il ne pourra tirer le maximum de la possibilité de réduire la paperasserie et de rationaliser ses flux d'information. De plus, pour éliminer les obstacles techniques, le gouvernement devrait faciliter la mise en oeuvre des interfaces normalisées de formulaires électroniques en offrant activement les services de soutien présentés à la section 8.

5. Définition type de la structure et du contenu des formulaires électroniques

5.1 Applications des logiciels de formulaires électroniques

Les applications de formulaires électroniques comprennent habituellement deux composantes logicielles distinctes, mais liées : la «conception» de formulaires et la «préparation» de formulaires. On recourt à la fonction de conception de formulaires pour agencer la disposition (ou le «modèle») du formulaire. La fonction de préparation permet aux utilisateurs de saisir des données dans le formulaire c'est-à-dire de le «remplir»

La création de modèles de formulaires exige des applications spéciales pour faciliter la tâche des gestionnaires de formulaires et les aider à établir des définitions uniformes et significatives.

La fonction de conception permet au gestionnaire de formulaires d'effectuer un croquis du formulaire à l'écran et d'en définir chacun des champs Ces types d'applications débouchent habituellement sur une définition de formulaire et une feuille de style propres (au fournisseur). La définition du formulaire renferme la liste des champs utilisés, de même que leur définition et les attributs liés, qui précisent les éléments suivants : les données de masquage, la sécurité, le type de données, la longueur des champs, etc. La feuille de style définit le «fond» du formulaire, par exemple les lignes verticales et horizontales, les cases, les étiquettes de champs et les instructions aux utilisateurs, et l'ombrage.

La fonction de préparation permet à l'utilisateur de consulter le formulaire à l'écran et de saisir des données dans les champs. À la lecture de la définition du formulaire et de la feuille de style fournie par la fonction de conception, la fonction de préparation peut non seulement permettre d'afficher le formulaire et d'en accepter les données, mais aussi de valider ces dernières en temps réel et d'effectuer des calculs à partir des données saisies par l'utilisateur. Par exemple, dans le cas d'un champ «date», la fonction de préparation ne permet que la saisie de la date pertinente. Lorsque l'utilisateur a terminé la saisie des données dans les champs du formulaire, l'information peut être enregistrée dans un fichier (habituellement propre à l'utilisateur) ou dans un schéma propre à l'utilisateur, à l'intérieur d'un système standard de gestion de base de données.

Les quatre (4) composantes principales suivantes sont nécessaires pour qu'une application de préparation de formulaires puisse présenter et traiter un formulaire électronique :

• des lignes directrices définissant la portée et les règles utilisées pour l'ensemble des formulaires électroniques;
• un modèle qui définit les champs du formulaire visé. (Le modèle est désigné à l'aide des règles énoncées dans les lignes directrices.);
• de l'information de traitement qui définit la disposition et le mode de traitement de l'information pour chaque champ du formulaire. (L'information de traitement est désignée à l'aide des règles énoncées dans les lignes directrices.);
• l'instance du formulaire contenant l'information saisie au cours d'une séance de préparation antérieure (élément facultatif).

Dans cette liste, l'information de traitement figure comme une composante unique. En réalité, elle se présente généralement sous forme d'information de définition des données (p. ex. des règles de validation des données, des définitions de champ et la valeur des codes), et d'information de présentation des données (p. ex. les zones d'affichage et les icônes, les polices, et la taille des caractères). Ce dernier type d'information est habituellement stocké sous forme de feuille de style, tandis que le premier type est conservé à l'intérieur du modèle.

Pour atteindre l'objectif principal du projet pilote d'interface normalisée des formulaires électroniques, la solution proposée doit favoriser l'échange des instances et de l'information sur la définition des données de formulaires produite par le logiciel classique de conception et de préparation des formulaires. Le mode d'échange de l'information est décrit aux sections suivantes. Il est également nécessaire d'échanger l'information sur la présentation des données entre les applications pour maintenir une structure vraiment «ouverte» permettant de définir d'abord les formulaires électroniques et ensuite de les utiliser dans toutes les applications de préparation de formulaires. Cette question est abordée à la section 7.2 intitulée «Stratégie d'échange proposée».

5.2 DTD unique pour l'ensemble des formulaires électroniques ou DTD pour chaque formulaire

Deux stratégies distinctes permettent d'appliquer les techniques de SGML à l'échange d'instances de formulaires et à la définition des données :

1. l'utilisation d'une DTD générique permettant de définir les règles pour tous les formulaires électroniques, suivie de l'utilisation d'instances de SGML non remplies et conformes à la DTD et permettant de définir les modèles de chaque formulaire;
2. l'utilisation de lignes directrices convenues permettant de définir les règles de création des DTD pour les formulaires électroniques, suivie de l'utilisation de DTD particulières conformes aux lignes directrices pour la définition des modèles de chaque formulaire (voir la Figure 2).

Dans la première option, tel qu'illustré ci-dessous, toutes les instances SGML de tous les formulaires électroniques sont conformes à une seule DTD.

Figure 1 : DTD générique unique de formulaire électronique

La DTD utilise des structures (c'est-à-dire des éléments SGML), comme des «intrants», pour définir un formulaire électronique. Un élément d'«intrant» correspond à un champ du formulaire. L'élément d'intrant possède des attributs qui définissent, entre autres, le nom, la taille et le genre du champ, les données de masquage et la sécurité.

Le modèle d'un formulaire particulier pourrait donc ressembler à ce qui suit :

<input name=today.date type=date size=8 mask="yy/mm/dd"></input>

<input name=first.name type=char size="1"0></input>

<input name=last.name type=char size="1"5></input>

Tandis que l'instance du formulaire électronique pourrait ressembler à ce qui suit :

<input name=today.date type=date size=8 mask="yy/mm/dd">96/03/31</input>

<input name=first.name type=char size="1"0>Samual</input>

<input name=last.name type=char size="1"5>Jones</input>

Comme le montrent ces exemples, le nom de l'élément est toujours «input» («intrant»), les attributs définissent la caractéristique de chaque champ et le contenu de l'élément correspond aux données saisies dans le champ par l'utilisateur de l'application de préparation du formulaire. Une démarche semblable serait appliquée aux structures de champ plus complexes, comme les groupes, les cases à cocher et les boutons radio. Dans ce scénario, une DTD définit les règles qui régissent la description de tous les formulaires électroniques.

Ce scénario offre d'importants avantages, notamment :

1. les règles qui régissent la définition d'un formulaire électronique sont appliquées uniformément, car elles peuvent être analysées par un module d'analyse SGML standard pour assurer le respect de la DTD;
2. les applications logicielles du formulaire électronique comportent une chaîne de travaux constante rigoureusement définie pour traiter toute instance de formulaire électronique.

Dans la deuxième option, les instances SGML sont conformes à la DTD qui définit chaque formulaire.

Figure 2 : DTD pour chaque formulaire électronique

Dans ce cas, chaque formulaire électronique peut utiliser des éléments différents pour définir les champs du formulaire. Par exemple, l'élément «first.name» (prénom) peut être défini pour le champ dont le contenu correspond au prénom de l'utilisateur, tandis que l'élément «last.name» (nom de famille) peut être défini pour le champ dont le contenu représente le nom de famille de l'utilisateur.

D'après l'exemple de l'option 1, un modèle pourrait prendre la forme suivante :

...

<today.date type=date size=8 mask="yy/mm/dd"></input>

<first.name type=char size="1"0></input>

<last.name type=char size="1"5></input>

...

Tandis que l'instance du formulaire électronique pourrait ressembler à ce qui suit :

<today.date type=date size=8 mask="yy/mm/dd">96/03/31</input>

<first.name type=char size="1"0>Samual</input>

<last.name type=char size="1"5>Jones</input>

La structure générale est semblable à celle de l'exemple précédent, sauf que le nom de l'élément est différent pour chaque champ. Il importe toutefois de noter que ce scénario comporte deux importants inconvénients :

1. les règles qui définissent chacune des DTD doivent être bien comprises et être mises en oeuvre de façon uniforme par tous les fournisseurs, car l'application informatisée de ces règles n'est pas une mince affaire (par exemple, une DTD peut comporter un attribut intitulé «size» (taille), tandis qu'une autre peut invoquer un attribut intitulé «length» (longueur) tout en désignant la même notion;
2. le traitement des éléments à l'aide de noms et de structures arbitraires représente une tâche beaucoup plus complexe que le traitement d'une série d'éléments possédant les mêmes nom et structure (p. ex. l'utilisation de l'élément «input» décrit au scénario précédent).

Au cours de la mise en oeuvre de ce projet pilote, on a constaté que les applications de formulaires électroniques les plus courantes étaient conçues comme une version personnalisée d'une DTD générique assortie d'un modèle exclusif pour chaque formulaire électronique (équivalent de l'option 1 ci-dessus). En d'autres termes, chaque fournisseur a conçu ses propres règles (incorporées à l'application ou conservées dans des fichiers de configuration) de définition des formulaires électroniques et les a appliquées pour créer des modèles de formulaire de même format (essentiellement des instances des règles). Par exemple, un modèle de formulaire représente généralement une liste de champs dont les attributs incluent le nom du champ, des données sur la sécurité et la validation, les codes de masquage, le programme de validation et le texte d'aide.

Pour appuyer une définition normalisée de la structure et du contenu des formulaires électroniques, on a recommandé, dans le cadre d'un sondage sur le rôle du SGML dans un contexte de formulaires électroniques, d'affecter une DTD distincte à chaque formulaire. Cette recommandation a été réexaminée à l'intérieur du projet pilote, à l'issue duquel il a été décidé que la méthode d'une DTD pour chaque formulaire (quoique applicable) ne représentait pas une solution facile. En conséquence, elle pourrait nuire à l'acceptation et à la mise en oeuvre d'une solution normalisée de la part des fournisseurs et elle compliquerait la gestion et l'implantation des formulaires électroniques normalisés par les utilisateurs.

Pour ces motifs les participants au projet pilote en sont venus à la conclusion que l'on devrait privilégier la solution de rechange (c'est-à-dire une DTD générique unique).

5.3 SGML et HTML

Le secteur des TI a quelque peu discuté du bien-fondé relatif du recours au HTML plutôt qu'au SGML pour définir les formulaires électroniques en vue d'appuyer l'échange entre les systèmes. Puisque HTML est un SGML simplifié, il serait plus exact de parler d'une comparaison entre le balisage HTML et une nouvelle ligne directrice utilisée pour appliquer le balisage SGML aux formulaires électroniques.

Tel que décrit à la section précédente, on peut définir des formulaires électroniques en utilisant SGML, puis soit une DTD générique pour tous les formulaires, soit une DTD distincte pour chacun. La version 3.2 de HTML applique aux formulaires électroniques une DTD générique qui ressemble à bien des égards à la DTD générique proposée dans le présent document. Les sections qui suivent décrivent le mode d'utilisation des formulaires HTML, précisent les motifs pour lesquels ces derniers ne peuvent satisfaire aux besoins des formulaires de gestion et indiquent de quelle façon HTML peut être élargi pour permettre l'exécution des fonction nécessaires.

6. Conception et traitement des formulaires

Cette section décrit sous l'angle d'Internet les fonctions génériques des applications de formulaires électroniques décrites à la section 5.1. Elle situe les fonctions de traitement offertes par HTML et permet de déterminer les fonctions qu'offriront les formulaires améliorés de type Java dans un avenir rapproché. En bref, elle présente un contexte qui réaffirme la stratégie dynamique recommandée dans l'ensemble du rapport au chapitre de la normalisation et de la mise en oeuvre des formulaires électroniques.

6.1 Traitement actuel des formulaires HTML

6.1.1 Traitement par IPC

Les formulaires HTML ont été conçus aux seules fins de demander et de recevoir des champs de données d'un navigateur Web client puis de les traiter en utilisant un logiciel sur serveur appelé au moyen d'une IPC (interface de passerelle commune). Cette configuration de traitement est illustrée à la figure 3 ci-dessous.

Les données saisies par un utilisateur dans des formulaires électroniques à l'aide d'un navigateur Web ne sont presque jamais utilisées dans une instance HTML. Le langage HTML est sert simplement utilisé pour créer l'affichage et faire en sorte que le navigateur Web demande et reçoive l'information. Habituellement, les données passent directement au programme d'IPC, qui les traite immédiatement et les sauvegarde dans une base de données ou les élimine.

Figure 3: Traitement actuel de formulaires HTML

Dans ce scénario, l'utilisateur du navigateur doit fournir des données précises après l'entrée en communication avec le serveur HTTP à un poste local ou éloigné. Les invites proviennent d'un formulaire HTML intégré dans une base de données liée au serveur HTTP. Les données saisies par l'utilisateur sont traitées par le logiciel d'application CGI qui atteste que les données fournies par l'utilisateur correspondent aux contraintes appliquées à chaque champ défini par le formulaire HTML.

Même si les données devaient être stockées dans le document HTML puis échangées, la norme HTML actuelle (HTML v3.2) ne permet pas l'échange de formulaires électroniques types de gestion. Par exemple, la version actuelle (HTML 3.2) n'offre pas de fonctions standard telles la vérification du type de données, la validation de la valeur des champs, les valeurs calculées, les masques, etc., pour lesquelles il faut adapter des scripts CGI (Common Gateway Interface). Ces fonctions supplémentaires constituent des exigences standard pour les formulaires électroniques et elles sont essentielles pour l'affichage et le traitement des données des formulaires. Il ne faut pas laisser aux programmes CGI (qui varient d'un serveur à l'autre) le soin de traiter les données.

6.1.2 Applications de type extensions (plug-ins)

Certains navigateurs Web acceptent des applications de type extensions (plug-in) qu'ils appellent dès qu'ils reçoivent un flux de données non HTML ou qu'ils ne peuvent traiter. L'enregistrement de l'en-tête du flux de données indique le type de données de la transmission, ce qui permet au navigateur d'appeler l'application d'extension appropriée dans l'ordinateur client.

Figure 4 : Applications de type extensions (plug-in)

Cette technique est celle qu'utilise actuellement au moins un fournisseur de formulaires électroniques pour traiter les formulaires électroniques sur le Web. Malheureusement, la version actuelle utilise les types de données propres au fournisseur et, par conséquent, aucune application de formulaires électroniques d'un autre fournisseur ne peut les traiter. On pourrait éviter ce problème en normalisant les types de données des formulaires électroniques pour permettre aux applications de plusieurs fournisseurs d'échanger des données des formulaires.

6.2 Traitement futur des formulaires HTML (Java)

On note actuellement une activité fébrile en vue d'améliorer les applications sur le Web. Le traitement des formulaires électroniques n'est qu'un des aspects qui subiront des changements importants au cours des deux prochaines années. L'immense intérêt que suscitent le langages Java et les scripts Java a une incidence sur ce que les applications de formulaires électroniques auront à offrir dans un avenir rapproché.

Java est un langage de programmation qui permet l'élaboration d'applications totalement indépendantes des plates-formes. Ce produit a été mis au point par Sun Microsystems puis présenté aux organismes intéressés pour fins d'approbation d'une norme internationale. Java permet à un réalisateur de créer une application (appelée «miniapplication», en anglais «applet») qu'il peut ensuite télécharger de n'importe quel noeud du réseau vers n'importe quel autre noeud. Ensuite, l'application peut être chargée de façon dynamique puis être exécutée immédiatement.

Figure 5 : «Miniapplications» Java

Les applications de préparation de formulaires deviendront fort probablement des «miniapplications» en langage Java ou JavaScript téléchargées automatiquement dans le poste de travail de l'utilisateur dès le traitement par un navigateur Web d'un document HTML contenant de l'information de balisage de formulaire électronique.

JavaScript est un langage de production de scripts qui permet de définir en détail des fonctions dynamiques dans un document HTML. Produit dérivé du logiciel Java, il est beaucoup plus simple à programmer. Ainsi, un document HTML peut inclure des fonctions dynamiques (p. ex. valider des valeurs de champs) que le navigateur Web peut utiliser dans l'ordinateur client sans recourir à des miniapplications Java ni à des interfaces CGI (Common Gateway Interfaces) de serveur.

Le Livre blanc «The Internet Application Framework: A White Paper» de Netscape propose l'exemple ci-après pour illustrer la puissance de JavaScript.

Une capacité simple, mais extrêmement utile illustre bien la puissance de JavaScript. Par le passé, pour traiter un formulaire HTML, l'utilisateur devait remplir différents champs, puis cliquer sur le bouton «Submit» pour faire acheminer le formulaire rempli vers un serveur où il était traité par un script CGI. L'utilisateur devait donc attendre que le formulaire fasse un trajet aller-retour sur le réseau, ce qui pouvait prendre plusieurs secondes. De plus, au retour, les résultats figuraient dans un nouveau document et non dans celui du formulaire original.

JavaScript enrichit le formulaire HTML en lui ajoutant un algorithme d'événement semblable à celui que l'on retrouve dans la plupart des IUG. Ainsi, les différents éléments d'un formulaire sont associés à des événements qui peuvent être déclenchés dès que l'utilisateur tape au clavier ou se sert de la souris. Ces événements sollicitent les fonctions de JavaScript qui ont été déclarées dans les en-têtes de document. Ce mécanisme permet une interaction immédiate avec l'utilisateur, de la simple vérification d'erreur à des calculs complexes dont les résultats s'affichent dans le formulaire original. L'utilisateur obtient une réponse immédiate et puisque JavaScript s'exécute dans le site client, il n'y a ni cheminement du document dans le réseau, ni appel de programme CGI distinct dans le serveur.

Bien que dans l'exemple on utilise des formulaires électroniques pour démontrer la puissance de JavaScript, on ne s'attend pas que ce produit élimine tout besoin d'applications de traitement de formulaires électroniques de gestion (ou «miniapplications», tel que décrit précédemment). Certains créateurs de HTML utiliseront sans doute JavaScript pour émuler une fonctionnalité semblable à celle d'une application de formulaires électroniques; toutefois, à moins d'un contrôle strict, il deviendra impossible de gérer de grandes quantités de formulaires possédant chacun des règles de traitement éventuellement différentes. Il semble que JavaScript soit des plus utiles pour la réception et la validation des données d'entrée des applications personnalisées.

Compte tenu de ce paradigme d'applications Java et JavaScript, les «miniapplications» de Java semblent offrir le meilleur mode d'application aux fins de la présentation et du traitement des formulaires électroniques sur le Web.

7. Exigences en matière d'échange de données

On peut utiliser autant de méthodes que l'on désire pour l'échange des formulaires, notamment :

• le courrier électronique
• le stockage et extraction en recourant à un système commun de gestion de documents, à un serveur Web ou à un système d'annuaire local;
• l'acheminement au moyen d'un système de gestion de flux de travail.

La méthode d'échange la plus répandue à l'heure actuelle est le courrier électronique. La plupart des applications de préparation de formulaires utilisent des méthodes qui leur sont propres pour l'échange de formulaires par courrier électronique entre utilisateurs. Généralement, l'échange s'effectue par la transmission de l'instance de formulaire dans un message de courrier électronique (ou parfois sous forme de pièce jointe) puis par l'intégration, dans l'application de préparation de formulaires, d'un système de courrier électronique local tel cc:mail. Habituellement, le processus de messagerie s'active automatiquement dès la réception d'un message contenant une chaîne d'en-tête particulière.

En soustrayant les données de formulaire au contrôle d'une application particulière ou même d'un environnement informatique spécifique, il devient de plus en plus nécessaire d'échanger d'autres types d'information, comme des feuilles de style ainsi que la définition du formulaire et ses données.

En plus de faciliter l'échange de données des formulaires électroniques, l'application de préparation des formulaires doit accepter le cryptage et les signatures numériques pour assurer l'intégrité et la confidentialité de chaque échange. Ces questions sont abordées plus en détail à la section 8.2, intitulée «Cryptage et signatures numériques».

7.1 Projet pilote de courrier électronique

Durant le projet pilote, on a utilisé une chaîne d'en-tête standard qui serait reconnue par les systèmes respectifs de courrier électronique pour activer les applications de formulaires électroniques de chaque fournisseur. Bien que cette solution soit exploitable, il serait plus facile de la mettre en oeuvre dans toutes les applications de courrier électronique en enregistrant un type MIME standard pour les formulaires électroniques échangés au moyen de la DTD normalisée décrite dans le présent rapport. Une extension semblable pourrait être créée pour les applications de courrier électronique fondées sur la norme X.400 de manière à assurer l'indépendance des normes de messagerie.

Figure 6 : Projet pilote de courrier électronique à interface

7.2 Stratégie d'échange proposée

Le Web a connu beaucoup de succès au chapitre de l'élaboration et de la mise au point des normes indépendantes des fournisseurs et des plates-formes. Le réseau a ainsi permis aux utilisateurs de communiquer et d'échanger des données dans tous les environnements informatiques, des plus simples terminaux à caractères aux ordinateurs les plus évolués. Il a également permis aux personnes handicapées d'interagir avec le Web grâce au Braille, à des polices de grands caractères, à la reconnaissance de la voix, etc. Un document HTML peut donc être consulté et affiché, le cas échéant, peu importe le navigateur utilisé par le destinataire.

Pour progresser, les utilisateurs de formulaires électroniques ont besoin de ce type d'échange. Pour échanger des formulaires, il faut également qu'il y ait échange entre plates-formes ainsi qu'avec des utilisateurs possédant des besoins particuliers. La fonctionnalité Web peut être exploitée en transmettant les données sur les formulaires à l'aide d'un fichier de données unique et en permettant à l'application de préparation de formulaires de sélectionner aux fins d'affichage une feuille de style.

Les utilisateurs du Web s'orientent de plus en plus vers l'utilisation de feuilles de style liées pour l'affichage de l'information plutôt que de laisser au navigateur Web le soin de déterminer la façon d'appliquer les styles. Il faut procéder à une analyse pour tester les méthodes actuelles de définition de feuille de style, telles DSSSL ou DSSSL Lite, afin de déterminer si elles sont en mesure de permettre l'échange de styles dans le cas des applications de formulaires de gestion.

7.3 Traitement de formulaires normalisés

Les applications actuelles de conception de formulaires électroniques devront être modifiées pour produire des résultats utiles à l'aide de la DTD standard appliquée aux formulaires et aux feuilles de style, de manière à assurer l'interface avec les applications de préparation de formulaires électroniques d'autres fournisseurs.

Une fois la DTD générique en place, on pourra utiliser les applications de préparation de formulaires sans recourir aux applications personnalisées de conception de formulaires. Les applications de préparation de formulaires pourront alors importer les définitions de formulaires et les feuilles de style créées par le logiciel concepteur de formulaires d'un autre fournisseur, selon le modèle de DTD générique défini à l'annexe A.

Dans l'environnement Web actuel, cette interopérabilité des deux types d'application susmentionnés que permet le Web s'apparente à la capacité d'un navigateur de lire puis d'interpréter un document HTML quel que soit l'outil de création HTML utilisé par son auteur. Un auteur qui crée un document HTML à l'aide de son propre outil HTML s'assure en quelque sorte que le navigateur, quelqu'il soit, sera capable de lire et d'interpréter correctement ce document. Une intégration semblable de la DTD générique et des modèles pertinents aux application actuelles de conception de formulaires électroniques permettrait aux gestionnaires des formulaires de définir de nouveaux modèles donnant aux utilisateurs la possibilité d'afficher ou d'établir le contenu du formulaire à l'aide d'un navigateur HTML ou d'une application de préparation de formulaires électroniques. Cette capacité de concevoir un formulaire à l'aide d'une application de conception sans recourir à l'application de préparation qui constitue l'élément fondamental du traitement des formulaires normalisés.

7.4 DTD générique proposée et modèles pertinents

La DTD proposée, qui est présentée à l'annexe A, a été rédigée dans l'optique du HTML et de l'échange de formulaires électroniques de gestion. En normalisant les types de données des formulaires électroniques, la DTD permet aux applications de plusieurs fournisseurs d'échanger et de traiter des données de formulaires d'une manière uniforme et significative. Ces renseignements sur les types de données pourraient être définis à l'extérieur du balisage HTML ou être intégrés à un langage de balisage HTML amélioré. La solution privilégiée, c'est-à-dire celle préconisée dans le présent rapport, consiste à élaborer un format de données SGML indépendant du HTML qui serait toutefois présenté au Comité W3 en vue d'être intégré éventuellement à la norme HTML.

La DTD générique et les modèles pertinents joueront un double rôle, c'est-à-dire :

• définir les règles régissant une instance complète de formulaire électronique pouvant être échangée entre les applications de formulaires électroniques, que ce soit dans des documents HTML ou sur le Web;
• définir l'extension à ajouter à la DTD HTML pour l'utilisation des formulaires électroniques dans les documents HTML et sur le Web.

Grâce à la définition de la DTD comme sous-ensemble de la DTD HTML, les utilisateurs ont accès à un outil de traitement et d'échange de formulaires électroniques plus dynamique et plus facile à appliquer.

8. Services centralisés

Pour assurer l'uniformité des formulaires et aider les utilisateurs à obtenir le formulaire désiré, il faut tenir compte de plusieurs aspects avant de procéder à une mise en application massive des formulaires électroniques normalisés.

Voici quelques-unes des questions auxquelles il faut répondre :

• comment pourrez-vous avoir accès à une définition de formulaire ou à une feuille de style (créée dans votre direction, votre direction générale ou votre ministère, ou dans un ministère ou un organisme distinct)?
• comment vous assurer d'utiliser la bonne version?
• comment vous assurer que des versions multiples d'un même formulaire ne sont pas créées simultanément?
• comment vous assurer de ne pas utiliser les mêmes définitions de type de données pour des champs communs dans l'ensemble des directions d'un ministère ou d'un secteur d'activité?

Pour répondre à ces questions, il faut envisager des solutions au plan de la technologie et de la gestion, sans oublier que la réussite des premières est intimement liée à la qualité de leur gestion.

8.1 Registre/dépôt centralisé

Dans une organisation aussi vaste que le gouvernement fédéral, il est absolument essentiel d'établir un registre/dépôt centralisé pour réussir à gérer toutes les définitions de formulaires électroniques interministérielles approuvées. Ces formulaires sont à ce point indispensables à la mission du gouvernement qu'on ne peut laisser à chaque ministère le soin de créer ses propres définitions dont il faudra ensuite essayer de résoudre les incompatibilités.

Une approche proactive est cruciale pour la conception des définitions de formulaires si l'on veut éviter les dédoublements et l'inefficience découlant de définitions incompatibles qui compromettent le traitement informatisé des données échangées par les ministères et les secteurs d'activité. Pour créer, mettre à jour et distribuer les formulaires électroniques, on n'a pas besoin d'un vaste service centralisé, mais plutôt d'un registre qui permette d'identifier les formulaires existants et d'en valider les définitions et les styles, et de tenir à jour une liste accessible des formulaires actuels et de leurs feuilles de style tout en s'assurant que tous ceux qui en ont besoin puissent y accéder.

L'ONGC (Office des normes générales du Canada) a été chargé par le Conseil du Trésor de normaliser tous les formulaires du gouvernement fédéral, qu'ils soient sur papier ou sur support électronique. Il va de soi que divers intervenants, technologies et compétences seront requises pour mettre en oeuvre des techniques, comme la production de formulaires SGML et implanter un registre/dépôt de DTD, comme il est proposé dans le présent rapport, que cet effort représente un investissement important et que l'appui et la collaboration des cadres supérieurs de l'administration fédérale sont essentiels pour la réussite de ce projet.

8.2 Cryptage et signatures numériques

Il est essentiel que l'information contenue dans un formulaire électronique parvienne intégralement à son destinataire et qu'elle ne soit pas altérée. En d'autres termes, il faut être en mesure de vérifier que les données échangées que reçoit le destinataire correspondent exactement à celles transmises par l'expéditeur.

Les cinq caractéristiques ci-après définissent les exigences essentielles à la sécurité du réseau :

• confidentialité : permet de s'assurer que les données ne sont ni divulguées à quiconque n'est pas autorisé à les recevoir, ni transmises à des ordinateurs non autorisés;
• contrôle d'accès : permet de s'assurer que l'accès aux données soit réservé à ceux qui sont autorisés à les consulter ou à les modifier;
• intégrité : permet de s'assurer que les données n'ont pas été altérées depuis leur création ou leur transmission;
• authentification de l'origine des données : permet de certifier la source des données;
• non-répudiation : permet de s'assurer que personne ne peut nier être partie d'une opération électronique à laquelle il a participé.

Le cryptage est lié aux exigences relatives à la confidentialité et au contrôle d'accès, et la signature numérique, à celles relatives à l'intégrité, à l'authentification et à la non-répudiation. Une signature numérique est une application de la cryptographie à clé publique qui identifie le «signataire» du document tout en verrouillant certains champs pour en éviter la modification.

Il y a deux catégories de cryptographie : la cryptographie à clé secrète et la cryptographie à clé publique. La cryptographie à clé secrète utilise une seule clé que se partagent les deux parties qui communiquent. Pour que ce type de cryptographie soit efficace, il faut que la clé demeure secrète et sous le contrôle des parties qui y ont accès. Une des principales percées dans le domaine de la cryptographie a été l'invention de la cryptographie à clé publique. Ce type de cryptographie utilise deux clés : une clé publique et une clé privée. Les deux sont reliées par algorithme mathématique et il est impossible de décrypter la clé privée à partir de la clé publique. Chaque partie possède sa propre paire de clés publique/privée. N'importe qui peut connaître la clé publique, mais personne ne doit pouvoir la modifier. La clé privée demeure secrète. Son propriétaire doit en contrôler l'utilisation et elle doit être protégée contre toute modification et toute divulgation.

Le principal avantage de la cryptographie à clé publique réside dans le fait qu'elle supprime l'obligation d'utiliser la même clé pour le cryptage et le décryptage. Le processus est essentiellement le suivant : on procède au cryptage de la transmission en utilisant la clé publique du destinataire; ce dernier utilise sa clé privée pour décrypter la transmission et la clé publique de l'expéditeur pour authentifier le message.

Le gouvernement du Canada travaille actuellement à l'installation d'une infrastructure à clé publique fondée sur du logiciel Entrust pour le cryptage et les signatures numériques de ses transmissions. Entrust est un produit commercial élaboré par Northern Telecom et qui, selon ses spécifications, est conforme, entre autres, aux normes suivantes :

• Cryptage - norme U.S. Data Encryption Standard (DES) en conformité avec les normes U.S. FIPS PUB 46-2 et ANSI X3.92.
• Signatures numériques - Digital Signatures en conformité avec les normes de RSA Data Security Inc. Normes Public Key Cryptographic Standards (PKCS), spécification PKCS #1. Norme de transmission de clé RSA Key Management en conformité avec les demandes RFC 1421 et 1423 (PEM) d'Internet.
• Format d'enveloppe de fichier - Fondé sur la demande RFC 1421 (PEM) d'Internet.
• Protocoles d'annuaire - Protocole d'accès à l'Annuaire (DAP) et Protocole du système d'annuaire (DSP) en conformité avec les normes ITU-T Rec. X.500.
• Protocole allégé d'accès à l'Annuaire (LDAP) en conformité avec la demande RFC 1487 d'Internet.

La stratégie d'échange de données de formulaires électroniques énoncée dans ce rapport ne devrait avoir aucune incidence sur la mise en oeuvre d'Entrust ou de tout autre produit conforme à ces normes. Il faut effectuer une analyse plus poussée afin de déterminer exactement dans quelle mesure une application de signature numérique peut permettre le verrouillage de champs ou de blocs de champs particuliers d'un formulaire électronique.

8.3 Archivage

L'archivage des instances de formulaires électroniques est une composante essentielle de la gestion globale du cycle de vie des formulaires et de saines pratiques de gestion. Il s'agit également d'une politique du gouvernement en matière de gestion des fonds d'information publique et de conservation des documents publics essentiels. Cependant, dans certains environnements de formulaires électroniques, comme ceux des instances de formulaires électroniques stockés dans des bases de données, et la mise en oeuvre des documents en version HTML, il n'existe aucune façon de sauvegarder les données comme des objets simples ou comme des fichiers globaux isolés de l'application de formulaires aux fins d'archivage.

Voici quelques-uns des principaux attributs d'un archivage réussi :

• stockage : capacité de stocker une instance complète du formulaire, y compris toutes les signatures numériques ainsi que les valeurs calculées;
• extraction : capacité d'extraire une instance complète d'un formulaire sans supposition au sujet de la disponibilité du matériel ou du logiciel qui ont été utilisés pour le créer;
• sécurité : voir les cinq principaux aspects liés à la sécurité susmentionnés, c'est-à-dire la confidentialité, l'accès aux données, l'intégrité, l'authentification des données et la non-répudiation.

L'utilisation de SGML pour l'échange de formulaires électroniques a une incidence marquée sur la capacité d'archivage et d'extraction des données des formulaires électroniques actuels. D'abord, il est possible d'utiliser le même modèle de données SGML pour l'échange et l'archivage des données. Cette capacité débouche donc sur une représentation normalisée du formulaire au complet, quel que soit le medium de stockage de données utilisé par l'application initiale qui a servi à sa création. Ensuite, puisque la structure des données archivées n'est pas propre au fournisseur, on peut utiliser n'importe quelle application conforme pour visualiser les données. Ainsi, on évite le traitement de données dont l'application n'est plus soutenue par un logiciel du fournisseur, et les situations où l'utilisateur n'archive pas l'application d'origine (et l'environnement informatique) avec les données.

9. Produits à livrer

Dans le cadre du projet, l'équipe a produit ce qui suit :

• une DTD pour chacun des deux échantillons de formulaire (voir les annexes B et C);
• un échantillon d'instance SGML conforme aux DTD pour chaque échantillon de formulaire (voir les annexe B et C);
• des programmes d'importation et d'exportation pour les applications de formulaire électronique de chaque fournisseur; l'échange réussi des données des formulaires entre les produits de deux fournisseurs (c'est-à-dire Form Filler de Jetform et Novell Informs de Craig Technologies) par courrier électronique entre des ministères fédéraux à l'aide d'applications de courrier électronique différentes (les interfaces de courrier électronique des systèmes de courrier électronique des ministères ont été interreliés au moyen de la passerelle X.400 des SGTI);
• un relevé des questions découlant de l'exécution des tâches susmentionnées;
• un prototype de description générique de la structure et du contenu (c'est-à-dire une DTD et un modèle) des formulaires électroniques fondé sur les résultats et les questions issus du projet pilote (voir l'annexe A);
• une stratégie de mise en oeuvre de la description normalisée des formulaires et de l'échange des données des formulaires électroniques au sein du gouvernement fédéral.

10. Conclusions

Ce projet de validation de principe s'est avéré très utile à bien des égards.

Voici les principales conclusions tirées de ce projet :

Il est possible d'importer et d'exporter des documents SGML à l'aide d'applications de préparation de formulaires;

• l'échange d'applications de courrier électronique est possible, quoique cette option soit parfois encombrante;
• les modèles fondés sur une seule DTD générique de formulaire électronique offrent la même fonctionnalité que des DTD spécifiques pour les formulaires particuliers et ils sont beaucoup plus faciles à appliquer;
• la version actuelle de HTML n'est pas suffisamment fonctionnelle pour permettre l'échange de données issues de formulaires électroniques à l'appui des opérations administratives et de gestion.

11. Recommandations

Le gouvernement du Canada doit accélérer le passage à une approche normalisée au chapitre de la description et de l'échange de données sur les formulaires électroniques. L'accroissement du nombre de fonctionnaires fédéraux qui utilisent les formulaires électroniques devra s'accompagner d'une augmentation du nombre de modèles et d'instances propres à des fournisseurs. Cette croissance globale des applications et des données incompatibles continuera d'entraver les efforts des fonctionnaires en vue d'échanger , de gérer et d'archiver l'information issue de ces applications propres aux fournisseurs. En adoptant des formulaires électroniques normalisés, le gouvernement pourrait accroître son efficience, son efficacité et sa capacité d'adaptation sans pour autant sacrifier la fonctionnalité qu'offrent actuellement les applications de formulaires électroniques ou le potentiel d'innovation des fournisseurs.

Après examen des objectifs, résultats et conclusions du projet pilote d'interface des formulaires électroniques, le Groupe de travail sur les normes des documents électroniques recommande au gouvernement d'accélérer la mise en place des formulaires électroniques normalisés en appliquant les mesures suivantes :

• utiliser la DTD exposée dans le présent document comme point de départ pour créer et examiner une spécification de DTD fonctionnelle et dynamique aux fins de l'échange de formulaires électroniques;
• faire en sorte que l'autorité chargée d'améliorer la DTD collabore étroitement avec le Comité W3 et soumette la DTD à l'examen de ce dernier à titre d'amélioration des documents HTML pour le traitement des formulaires;
• veiller à ce que l'autorité collabore avec SGMLOpen et soumette la DTD à l'examen de ce dernier et à d'autres groupes de collaborateurs de l'industrie à titre de norme d'échange de formulaires électroniques;
• faire en sorte que l'autorité s'efforce d'enregistrer la DTD comme un type MIME standard aux fins de l'échange de formulaires électroniques par courrier électronique;
• s'assurer que le Groupe de travail sur les normes des documents électroniques, appuyé par des experts des formulaires, des organismes de normalisation et l'industrie des formulaires électroniques, poursuive l'examen des questions liées à l'échange de feuilles de style, à la sécurité, à la signature numérique, au cryptage et à l'archivage des formulaires électronique en vue d'élaborer une ligne directrice détaillée portant sur l'échange et l'archivage des formulaires électroniques, et formule des recommandations;
• mettre sur pied, au sein du gouvernement fédéral, un registre central chargé d'enregistrer et de gérer dans des systèmes distribués les originaux de chaque modèle de formulaire électronique et les documents qui s'y rattachent (p. ex. les descriptions des données communes, des feuilles de style, des logos);
• veiller à ce que le gouvernement favorise le respect de ces normes aux fins de l'acquisition future d'applications de formulaires électroniques.

Annexe A : DTD de formulaire électronique

<!DOCTYPE eform [

<!-- ************************************************************************** */

/* */

/* Fichier : eform.dtd */

/* Créé par : Larry Osipenko larry@idc.com */

/* InfoDesign Corporation */

/* Propr. : Gouvernement du Canada */

/* Fonction : Définition de type de document de formulaires électroniques */

/* */

/* Comment. : Cette DTD a été créée dans le contexte du projet d'essai SGML*/

/* des formulaires électroniques. Ce prototype n'est qu'une */

/* première version et peut être modifié de façon radicale. */

/* */

/* Cette DTD vise à permettre l'échange autonome entre */

/* applications de formulaires électroniques et à donner un */

/* aperçu d'un fragment de DTD utilisable dans HTML pour les */

/* formulaires électroniques. */

/* */

/* Tous les champs qui peuvent recevoir des */

/* données ont été regroupés dans une définition d'élément autre*/

/* que les éléments */

/* de tables et d'images. Sont inclus les champs à sélections */

/* multiples et multilignes. */

/* */

/* Cela simplifie considérablement la DTD. Toutefois, à titre */

/* d'exercice ultérieur, il serait probablement utile de créer */

/* un élément distinct pour chaque type d'entrée afin de mieux */

/* définir les attributs de chaque type. */

/* */

/* On prévoit que l'information de «présentation» accompagne */

/* éventuellement l'information contenue dans une instance de */

/* cette DTD. Cette information peut prendre la forme d'une */

/* feuille de style DSSSL ou DSSSL Lite, ou d'un modèle à */

/* élaborer conçu spécialement pour les formules électroniques */

/* à éviter) ou d'un document HTLM entourant le formulaire. */

/* Il faut poursuivre les travaux pour définir comment */

/* l'information de présentation sera traitée simultanément*/

/* avec l'instance de cette DTD et comment elle lui sera reliée.*/

/* */

/* Cette DTD n'a pas été mise à l'essai et doit être examinée */

/* et testée par un comité d'élaboration de DTD de formulaire */

/* électronique avant qu'on puisse l'utiliser. */

/* */

/* Identificateur public : */

/* La déclaration doctype de chaque instance de cette DTD doit */

/* inclure ce qui suit : */

/***************************************************************************/

<!Doctype eform PUBLIC "-//CDN-GOV//DTD E-FORM//EN" [

]>

/***************************************************************************/

/* */

/* Histor. : */

/* */

/* V1.0 */

/* ate : 31 mars 1996 */

/* Créé par : Larry Osipenko */

/* InfoDesign Corporation */

/* larry@idc.com */

/* En vertu d'un contrat avec le gouvernement fédéral du Canada*/

/* */

/* */

/************************************************************************-->

<!--================ Entités mnémoniques de caractères====================-->

<!ENTITY % ISOLAT1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN">

%ISOLAT1;

<!ENTITY % ISONUM PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN">

%ISONUM;

<!ENTITY % ISOPUB PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN">

%ISOPUB;

<!ENTITY % ISOTECH PUBLIC "ISO 8879:1986//ENTITIES General Technical//EN">

%ISOTECH;

<!ENTITY % ISOAMS PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN">

<!ENTITY % ISOGRK3 PUBLIC "ISO 8879:1986//ENTITIES Greek Symbols//EN">

%ISOGRK3;

<!ENTITY % FORM.Version "1.0">

<!ENTITY % version.attr "VERSION CDATA #FIXED '%FORM.Version;'">

<!ENTITY % URL "CDATA"

-- Le terme URL désigne un attribut CDATA dont

la valeur est une adresse W3.

Voir les RFC1808 (juin 95) et RFC1738 (décembre 1994).

-->

<!--=================== Balisage de texte =================================-->

<!ENTITY % font "TT | I | B | STRIKE | BIG | SMALL | SUB | SUP">

<!ENTITY % phrase "EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE">

<!ENTITY % text "#PCDATA | %phrase | %font | IMG">

<!ELEMENT (%font|%phrase) - - (%text)*>

<!--================ Formulaires ==========================================-->

<!ENTITY % form.content "(INPUT | IMG | TABLE)">

<!ELEMENT EFORM - - %form.content>

<!ATTLIST EFORM

%version.attr

name CDATA #REQUIRED -- désigne le nom du modèle de formulaire

électronique et doit être rempli au momement de la

création du modèle --

templver CDATA #REQUIRED -- version du modèle de formulaire

électronique --

<!ENTITY % InputType

"(TEXT | PASSWORD | CHECKBOX | RADIO |

BUTTON | HIDDEN | IMAGE | SIGNATURE)">

<!ELEMENT INPUT - O (%text)*>

<!ATTLIST INPUT

type %InputType TEXT -- genre de composant requis --

name CDATA #REQUIRED -- requis pour tous les types, sauf

soumettre et restaurer --

group CDATA #IMPLIED -- nom du groupe où figure le champ --

checked (checked) #IMPLIED -- pour les boutons radio et les cases à

cocher --

size CDATA #IMPLIED -- propre à chaque type de champ --

rows NUMBER #IMPLIED -- nombre de rangées d'entrée --

maxlength NUMBER #IMPLIED

cols NUMBER #IMPLIED -- nombre de colonnes d'entrée --

default CDATA #IMPLIED-- valeur implicite à afficher --

label CDATA #IMPLIED -- étiquette utilisée pour le champ --

selection CDATA #IMPLIED -- liste des valeurs d'entrée possibles,

possibilité d'un affichage semblable à celui d'une

liste de sélection --

align (top|middle|bottom|left|right) top -- alignement d'image --

nextfield CDATA #IMPLIED -- champ suivant où le curseur doit se

se déplacer après le traitement du champ actuel --

help CDATA #IMPLIED -- texte d'aide --

mandatory (mandatory | optional) optional -- entrée de données

obligatoire? --

picture CDATA #IMPLIED -- masque de données

exemple : (999) 999-9999 --

validation CDATA #IMPLIED -- les types et la syntaxe des validations

ne sont pas encore définis. Exemples : numérique,

non zéro, date, instructions case ou if fondées sur

d'autres champs du formulaire, etc. --

calculation CDATA #IMPLIED -- les types et la syntaxe des calculs

automatiques ne sont pas encore définis.

Exemples : additions et multiplications fondées sur

d'autres champs, instructions SQL, etc. --

errmsg CDATA #IMPLIED -- message d'erreur à afficher. Les messages

peuvent également être affichés à partir d'une

instruction case de calcul ou de validation --

lockfields CDATA #IMPLIED -- obligatoire pour type=SIGNATURE --

>

<!--=================== Images ============================================-->

<!ENTITY % Length "CDATA" -- nn pour les pixels ou nn% pour la longueur

en pourcentage -->

<!ENTITY % Pixels "CDATA" -- nombre entier représentant la longueur en

pixels -->

<!-- Les largeurs suggérées servent à négocier la taille de

l'image avec le module de gestion de traçage d'image.

Le paramètre align="left" ou right fait se déplacer l'image

vers la marge et permet son enveloppement par le texte qui suit -->

<!ENTITY % IAlign "(top|middle|bottom|left|right)">

<!ELEMENT IMG - O EMPTY -- Image intégrée -->

<!ATTLIST IMG

src %URL #REQUIRED -- URL de l'image à intégrer --

alt CDATA #IMPLIED -- à afficher au lieu de l'image --

align %IAlign #IMPLIED -- alignement vertical ou horizontal --

height %Pixels #IMPLIED -- hauteur suggérée en pixels --

width %Pixels #IMPLIED -- largeur suggérée en pixels --

border %Pixels #IMPLIED -- largeur suggérée de la marge de

liaison --

hspace %Pixels #IMPLIED -- lézarde horizontale suggérée --

vspace %Pixels #IMPLIED -- lézarde verticale suggérée --

usemap %URL #IMPLIED -- utiliser la config. d'image de

client --

ismap (ismap) #IMPLIED -- utiliser la config. d'image de

serveur --

>

<!-- Le paramètre USEMAP renvoie à l'élément MAP qui peut figurer

dans ce document ou dans un autre document; toutefois, le soutien de

la dernière option n'est pas très répandu -->

<!--======================= Tables ========================================-->

<!-- Sous-ensemble très répandu de la norme complète de table HTML; voir RFC

XXXX -->

<!-- placement horizontal de la table par rapport à la fenêtre -->

<!ENTITY % Where "(left|center|right)">

<!-- attributs d'alignement horizontal du contenu des cellules -->

<!ENTITY % cell.halign

"align (left|center|right) #IMPLIED"

>

<!-- attributs d'alignement vertical du contenu des cellules -->

<!ENTITY % cell.valign

"valign (top|middle|bottom|baseline) #IMPLIED"

>

<!ELEMENT table - - (caption?, tr+)>

<!ELEMENT tr - O (th|td)*>

<!ELEMENT (th|td) - O (%text)*>

<!ATTLIST table -- élément de table --

align %Where #IMPLIED -- position de la table par rapport à la

fenêtre --

width %Length #IMPLIED -- largeur de la table par rapport à la

fenêtre --

border %Pixels #IMPLIED -- contrôle la largeur du cadre de la

table --

cellspacing %Pixels #IMPLIED -- espacement entre les cellules --

cellpadding %Pixels #IMPLIED -- espacement dans les cellules --

>

<!ELEMENT CAPTION - - (%text)* -- légende de table ou de figure -->

<!ATTLIST CAPTION

align (top|bottom) #IMPLIED

>

<!ATTLIST tr -- rangée de table --

%cell.halign -- alignement horizontal dans les

cellules --

%cell.valign -- alignement vertical dans les cellules --

>

<!ATTLIST (th|td) -- cellule d'en-tête ou de données --

nowrap (nowrap) #IMPLIED -- suppression du bouclage --

rowspan NUMBER 1 -- nombre de rangées recouvertes par les

cellules --

colspan NUMBER 1 -- numbre de colonnes recouvertes par les

cellules --

%cell.halign -- alignement horizontal dans les

cellules --

%cell.valign -- alignement vertical dans les cellules --

>

]>

Annexe B : Formulaire Convention de services

DTD de la Convention de services

Note : La DTD ci-dessous a été produite à l'aide de l'approche recommandée prévoyant une DTD par formulaire électronique. Elle a été créée au début du projet et a été utilisée au cours du projet pilote. À la suite de ce projet, il est recommandé d'appliquer la DTD présentée à l'annexe A. La DTD ci-dessous n'est reproduite qu'à titre de complément d'information et il n'est pas recommandé de l'utiliser pour définir un échange de formulaire électronique.

<!DOCTYPE service [

<!-- ***********************************************************************/

/* */

/* Fichier : service.dtd */

/* Créé par : Larry Osipenko larry@idc.com */

/* InfoDesign Corporation */

/* Propr. : Gouvernement du Canada */

/* Fonction : Définition de type de document du formulaire électronique */

/* Convention particulière de services */

/* */

/* Comment. : Cette DTD a été créée dans le cadre du projet d'essai SGML */

/* des formulaires électroniques. À ce titre, le formulaire n'a*/

/* fait l'objet d'aucune redéfinition. Les éléments et les */

/* attributs de la DTD doivent correspondre exactement aux */

/* formulaires électroniques existants. */

/* */

/* Identificateur public : */

/* La déclaration doctype de chaque instance de cette DTD doit */

/* inclure ce qui suit : */

/***************************************************************************/

<!Doctype service PUBLIC "-//CDN-GOV//DTD SERVICE E-FORM//EN" [

]>

/***************************************************************************/

/* */

/* Histor. : */

/* */

/* V1.0 */

/* Date : 22 mars 1996 */

/* Créé par : Larry Osipenko */

/* InfoDesign Corporation */

/* */

/* Comment. : 1. Chaque fois que c'est possible, nous avons utilisé les */

/* mêmes noms d'élément que ceux utilisés dans le formulaire */

/* électronique créé initialement par Ressources naturelles */

/* Canada. Ce projet ne visait pas à élaborer des normes */

/* d'attribution de noms aux éléments SGML. */

/* */

/* 2. Dans cette DTD, on utilise des attributs pour définir les */

/* champs du formulaire électronique représentés par des */

/* boutons radio ou des listes à cocher. La valeur de */

/* l'attribut indique le bouton radio ou la case à cocher */

/* sélectionné. Dans le cas des cases à cocher, toute */

/* valeur autre que zéro, ou qu'une valeur nulle, indique */

/* que la case est cochée. En général, la valeur «1» */

/* indique que la case est cochée. */

/* */

/* 3. Tous les éléments sont associés à des commentaires où */

/* figure le numéro du champ dans le formulaire. On n'a pas */

/* attribué de numéro de champ aux éléments qui sont */

/* réutilisés dans la DTD, par exemple les champs LIGNE, */

/* NOM, etc. Les numéros de champ des éléments réutilisables*/

/* sont définis par les éléments auxquels ils appartiennent. */

/* Les numéros de champ ont été indiqués pour aider les */

/* fournisseurs de formulaires électroniques et les */

/* examinateurs de cette DTD à comprendre la façon dont les */

/* éléments sont reliés au formulaire original. */

/*************************************************************************-->

!ENTITY % TEXT "(#PCDATA)" --<Titre>TEXTE-- >

<!ENTITY % yesorno "NUMBER" --<Titre>Oui ou Non -- >

<!ELEMENT SERVICE - - (ORIGIN-USE, AUTHORIZATION)

--<Titre>Élément de base du formulaire Convention

particulière de services --

• -Élément de base du formulaire complet--
• -Champs 1-29--

>

<!ELEMENT ORIGIN-USE - - (NAME, (EST-REQUEST | IMP-REQUEST), DATE, TELNO, SERI-NO?, FILENO?, PROJNO?, DESCRIP?, INV-ADDR?, DATE-REQ?, BUDGET?, SPEC-INSTR?, FIN-CODE?)

• -<Titre>Champs utilisés par l'initiateur--
• -Cet élément contient tous les éléments réservés

à l'initiateur. --

--Champs 1-25--

>

<!ELEMENT NAME - - (%TEXT;)

• -<Titre>Nom de la personne--
• -Champ 1 --

>

<!ELEMENT EST-REQUEST - o EMPTY

• -<Titre>Demande de prévision?--
• -Groupe de boutons radio pour choisir une prévision originale ou une modification.--
• -Champs 2,3 --

>

<!ELEMENT IMP-REQUEST - o EMPTY

• -<Titre>Demande d'exécution?--
• -Groupe de boutons radio pour choisir soit une demande d'exécution originale ou une modification--
• -Champs 4,5 --

>

<!ELEMENT DATE - - (%TEXT;)

• -<Titre>Date--
• -Taper AA-MM-JJ--
• -Champ 6 --

>

<!ELEMENT TELNO - - (%TEXT;)

• -<Titre>Numéro de téléphone--
• -Ne taper ni les tirets ni les parenthèses--

>

<!ELEMENT SERI-NO - - (%TEXT;)

• -<Titre>Numéro de série--
• -Numéro de série de la demande--
• -Champ 8 --

>

<!ELEMENT FILENO - - (%TEXT;)

• -<Titre>Numéro du dossier--
• -Numéro du dossier de la demande--
• -Champ 9 --

>

<!ELEMENT PROJNO - - (%TEXT;)

• -<Titre>Numéro de projet--
• -Numéro de projet visé par la demande--
• -Champ 10 --

>

<!ELEMENT DESCRIP - - (Line, (Line, Line?)?)

• -<Titre>Description et endroit des services--
• -Description et endroit du service à offrir--
• -Champ 11 --

>

<!ELEMENT LINE - - (%TEXT;)

• -<Titre>Ligne d'entrée unique--
• -Utilisé lorsqu'il est permis d'utiliser des lignes d'entrée multiples pour un élément donné.--

>

<!ELEMENT INV-ADDR - - (LINE , (LINE, LINE?)?) --<Titre>Adresse d'expédition de la facture--

• -Adresse postale complète où la facture sera expédiée; utiliser des lignes multiples au besoin.--
• -Champs 12,13,14--

>

<!ELEMENT DATE-REQ - - (%TEXT;)

• -<Titre>Date limite--
• -Date à laquelle le service doit être rendu et terminé. Utiliser AA-MM-JJ.--
• -Champ 15 --

>

<!ELEMENT BUDGET - - (YEAR1?, YEAR2?, YEAR3?, TOTAL)

• -<Titre>Limites budgétaires du client par année--
• -Champs 16-22 --

>

<!ELEMENT YEAR1 - - (YEAR, AMOUNT)

• -<Titre>Budget du client - an 1--
• -Champs 16,17 --

>

<!ELEMENT YEAR2 - - (YEAR, AMOUNT)

• -<Titre>Budget du client - an 2--
• -Champs 18,19 --

>

<!ELEMENT YEAR3 - - (YEAR, AMOUNT)

• -<Titre>Budget du client - an 3--
• -Champs 20,21 --

>

<!ELEMENT YEAR - - (%TEXT;)

• -<Titre>ANNÉE--
• -Champ à deux chiffres de l'année - AA--

>

<!ELEMENT AMOUNT - - (%TEXT;)

--<Titre>Budget du client - année particulière--

>

<!ELEMENT TOTAL - - (%TEXT;)

• -<Titre>Budget total du client--
• -Budget total du client - toutes les années--
• -Champ 22 --

>

<!ELEMENT SPEC-INSTR - - (LINE, (LINE, (LINE, (LINE, LINE?)?)?)?)

• -<Titre>Instructions particulières--
• -Description textuelle de toute instruction spéciale jugée nécessaire--
• -Champs 23,24--

>

<!ELEMENT FIN-CODE - - (%TEXT)

• -<Titre>Code financier du client--
• -Code financier du client--
• -Champ 25--

>

<!ELEMENT AUTHORIZATION - - (NAME, DATE, TITLE, TELNO)

• -<Titre>Information sur la personne autorisée--
• -Nom, date de signature, titre, numéro de téléphone de la personne autorisée.--
• -Champs 26-29--

>

<!ELEMENT TITLE - - (%TEXT;)

• -<Titre>Titre du poste de la personne--
• -Titre du poste de la personne--
• -Champ 28 --

>

<!ATTLIST SPEC-INSTR

ATTACHMENT %yesorno #IMPLIED

• -<Titre>Case à cocher de pièces jointes--
• -Case à cocher pour indiquer s'il y a des pièces jointes au formulaire--
• -Champ 23--

>

<!ATTLIST EST-REQUEST

TYPE (ORIGINAL, AMENDMENT) #REQUIRED

• -<Titre>Type de demande d'estimation--
• -Groupe de boutons radio pour indiquer le type de la demande d'estimation--

>

<!ATTLIST IMP-REQUEST

TYPE (ORIGINAL, AMENDMENT) #REQUIRED

• -<Titre>Type de demande d'exécution--
• -Groupe de boutons radio pour désigner le type de demande d'exécution--

>

<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN"

--<Titre>ISOlat1--

>

<!ENTITY % ISOgrk3 PUBLIC "ISO 8879-1986//ENTITIES Greek Symbols//EN"

--<Titre>ISOgrk3--

>

<!ENTITY % ISOnum PUBLIC

"ISO 8879-1986//ENTITIES Numeric and Special Graphic//EN"

--<Titre>ISOnum--

>

<!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN"

--<Titre>ISOpub--

>

<!ENTITY % ISOtech PUBLIC

"ISO 8879-1986//ENTITIES General Technical//EN"

--<Titre>ISOtech--

>

%ISOgrk3;

%ISOlat1;

%ISOnum;

%ISOpub;

%ISOtech;

]>

Instance de Convention de service

<!DOCTYPE SERVICE PUBLIC "-//CDN-GOV//DTD SERVIVE E-FORM//EN" "service.dtd">

<SERVICE><ORIGIN-USE><NAME>James Underhood</NAME>

<EST-REQUEST TYPE="ORIGINAL">

<DATE>96-03-21</DATE>

<TELNO>613 567-9587</TELNO>

<SERI-NO>88888888</SERI-NO>

<FILENO>123-45687-A0</FILENO>

<PROJNO>ABC-987654-12</PROJNO>

<DESCRIP><LINE>This is where you would enter a</LINE>

<LINE>description of the service to be provided</LINE>

<LINE>and where it is to be provided.</LINE></DESCRIP>

<INV-ADDR><LINE>Accounts Payable</LINE>

<LINE>Natural Resources Canada</LINE>

<LINE>580 Booth Street, Ottawa, ON</LINE></INV-ADDR>

<BUDGET><YEAR1><YEAR>96</YEAR>

<AMOUNT>$1,000,000</AMOUNT></YEAR1>

<YEAR2><YEAR>97</YEAR>

<AMOUNT>$500,000</AMOUNT></YEAR2>

<YEAR3><YEAR>98</YEAR>

<AMOUNT>$750,000</AMOUNT></YEAR3>

<TOTAL>$2,250,000</TOTAL></BUDGET>

<SPEC-INSTR ATTACHMENT="1"><LINE>See the plans attached.</LINE>

<LINE>Alternative plans can be viewed at my office.</LINE></SPEC-INSTR>

<FIN-CODE>XYZ-FIN-CODE</FIN-CODE></ORIGIN-USE>

<AUTHORIZATION><NAME>Mary Brown</NAME>

<DATE>96-03-22</DATE>

<TITLE>Supervisor</TITLE>

<TELNO>819 993-9876</TELNO></AUTHORIZATION></SERVICE>

Annexe C : Formulaire Demande de traduction

DTD de la Demande de traduction

Note : La DTD ci-dessous a été produite à l'aide de l'approche recommandée prévoyant une DTD par formulaire électronique. Elle a été créée au début du projet et a été utilisée au cours du projet pilote. À la suite de ce projet, il est recommandé d'appliquer la DTD présentée à l'annexe A. La DTD ci-dessous n'est reproduite qu'à titre de complément d'information et il n'est pas recommandé de l'utiliser pour définir un échange de formulaire électronique.

<!DOCTYPE translat [

<!-- ***********************************************************************/

/* */

/* Fichier : service.dtd */

/* Créé par : Larry Osipenko larry@idc.com */

/* InfoDesign Corporation */

/* Propr. : Gouvernement du Canada */

/* Fonction : Définition de type de document du formulaire électronique */

/* de la Demande de traduction */

/* */

/* Comment. : Cette DTD a été créée dans le contexte du projet d'essai SGML*/

/* des formulaires électroniques. À ce titre, le formulaire n'a*/

/* fait l'objet d'aucune redéfinition. Les éléments et les */

/* attributs de la DTD doivent correspondre exactement aux */

/* formulaires électroniques existants. */

/* */

/* Identificateur public : */

/* La déclaration doctype de chaque instance de cette DTD doit */

/* inclure ce qui suit : */

/***************************************************************************/

<!Doctype translat PUBLIC "-//CDN-GOV//DTD TRANSLATION E-FORM//EN" [

]>

/***************************************************************************/

/* Histor. : */

/* */

/* V1.0 */

/* Date : 22 mars 1996 */

/* Créé par : Larry Osipenko */

/* InfoDesign Corporation */

/* */

/* Comment. : 1. Chaque fois que c'est possible, nous avons utilisé les */

/* mêmes noms d'élément que ceux utilisés dans le formulaire */

/* électronique créé initialement par Ressources naturelles */

/* Canada. Ce projet ne visait pas à élaborer des normes */

/* d'attribution de noms pour les éléments SGML. */

/* */

/* 2. Dans cette DTD, on utilise des attributs pour définir les */

/* champs du formulaire électronique représentés par des */

/* boutons radio ou des listes à cocher. La valeur de */

/* l'attribut indique le bouton radio ou la case à cocher */

/* sélectionné. Dans le cas des cases à cocher, toute */

/* valeur autre que zéro, ou qu'une valeur nulle, indique */

/* que la case est cochée. En général, la valeur «1» */

/* indique que la case est cochée. */

/* */

/* 3. Tous les éléments sont associés à des commentaires où */

/* figure le numéro du champ dans le formulaire. On n'a */

/* pas attribué de numéro de champ aux éléments qui sont */

/* réutilisés dans la DTD, par exemple les champs LIGNE, */

/* NOM, etc. Les numéros de champ des éléments réutilisables*/

/* sont définis par les éléments auxquels ils appartiennent. */

/* Less numéros de champ ont été indiqués pour aider les */

/* fournisseurs de formulaires électroniques et les */

/* examinateurs de cette DTD à comprendre la façon dont les */

/* éléments sont reliés au formulaire original. */

/* */

/***********************************************************************-->

<!ENTITY % TEXT "(#PCDATA)" --<Titre>TEXT-- >

<!ENTITY % yesorno "NUMBER" --<Titre>Oui ou Non-- >

<!ELEMENT TRANSLAT - - (HEADER , ORIGIN-USE , (COORD-USE , BUREAU-USE?)?)

• -<Titre>Élément de base du formulaire de traduction--
• -Élément de base du formulaire complet--

>

<!ELEMENT HEADER - - (RG-REQ-NO2 , COTESEC)

• -<Titre>Identification du formulaire et information de sécurité--
• -Information d'en-tête figurant dans le coin supérieur droit du formulaire--
• -Champs 101, 1--

>

<!ELEMENT ORIGIN-USE - - (DEPART , BRANCH , DIVISION , TX-ORIG-FILE? ,

ORIGIN , AUTHOR? , TX-DOC-TITLE , TX-SUB-DATE ,

TX-WISH-DATE , SRCLANG , TGTLANG , DELIVERY , INCL , USE ,

PREVREQ? , SPEC-INSTR , AUTHORITY , NOPAGE? , CERT? ,

NAMELIB?) --<Title>Originator Use Fields--

• -Cet élément contient tous les éléments réservés au demandeur.--
• -Champs 2-53--

>

<!ELEMENT COORD-USE - - (DOC-TYPE , RCV-DATE , PRIORITY , REMARKS? ,

POLICY , COORD)

• -<Titre>Champs réservés au coordonnateur--
• -Cet élément contient tous les éléments réservés au coordonnateur de la traduction.--
• -Champs 55-72--

>

<!ELEMENT COTESEC - O EMPTY

• -<Titre>Cote de sécurité--
• -Si le texte a une cote de sécurité, vérifier qu'on peut le transmettre électroniquement--
• -Champ 1--

>

<!ELEMENT DEPART - - (LINE , LINE? , TX-CODE) --<Titre>Nom du ministère--

--Champs 2,3--

>

<!ELEMENT TX-CODE - - (%TEXT;) --<Titre>Code de ministère--

• -Code du ministère attribué par le Bureau de la traduction. Sert aux fins de facturation.--
• -Champ 3--

>

<!ELEMENT BRANCH - - (LINE , LINE? , TX-BRANCH) --<Titre>Nom de la direction générale--

--Champs 4,5--

>

<!ELEMENT TX-BRANCH - - (%TEXT;) --<Titre>Code de la direction générale--

• -Code de la direction générale attribué par le Bureau de la traduction. Sert aux fins de facturation.--
• -Champ 5--

>

<!ELEMENT DIVISION - - (LINE , LINE? , TX-DIVISION) --<Titre>Nom de la division--

--Champs 6,7--

>

<!ELEMENT TX-DIVISION - - (%TEXT;) --<Titre>Code de la division--

• -Code de la division attribué par le Bureau de la traduction--
• -Champ 7--

>

<!ELEMENT TX-ORIG-FILE - - (%TEXT;)

• -<Titre>Référence du demandeur--
• -Champ 8--

>

<!ELEMENT ORIGIN - - (NAME , POSTIT , TELNO , ADDR) --<Titre>Information sur le demandeur--

--Champs 9-15--

>

<!ELEMENT NAME - - (%TEXT;) --<Titre>Nom de la personne--

>

<!ELEMENT POSTIT - - (%TEXT;) --<Titre>Titre du poste--

--Champ 12--

>

<!ELEMENT TELNO - - (%TEXT;)

• -<Titre>Numéro de téléphone du demandeur--
• -Ne pas taper les tirets ni les parenthèses--

>

<!ELEMENT ADDR - - (LINE , LINE? , POSTCODE) --<Titre>Adresse postale--

• -Adresse postale complète, utiliser des lignes multiples au besoin.--
• -Champ 14--

>

<!ELEMENT POSTCODE - - (%TEXT;) --<Titre>Code postal--

--Champ 15--

>

<!ELEMENT AUTHOR - - (NAME , TELNO) --<Titre>Information sur l'auteur--

• -L'auteur est la personne qui a rédigé le texte à traduire ou une personne-ressource qui peut répondre aux demandes de renseignements du traducteur.--
• -Champs 16-19--

>

<!ELEMENT TX-DOC-TITLE - - (%TEXT;)

• -<Titre>Titre ou description du document--
• -Champ 20--

>

<!ELEMENT TX-SUB-DATE - - (%TEXT;) --<Titre>Soumis le--

• -Taper 6 chiffres seulement (sans les tirets), comme suit : AAMMJJ--
• -Champ 21--

>

<!ELEMENT TX-WISH-DATE - - (DATE , TGHOUR?) --<Titre>Retour souhaité--

• -Taper la date de retour souhaité. Taper 6 chiffres seulement (AAMMJJ)--
• -Champs 22,23--

>

<!ELEMENT TGHOUR - - (%TEXT;)

• -<Titre>Heure du retour souhaité--
• -Taper l'heure du retour souhaité. Taper uniquement 4 chiffres (HHMM)--
• -Champ 23--

>

<!ELEMENT SRCLANG - - (%TEXT;) --<Titre>Langue de départ--

--Champ 24--

>

<!ELEMENT TGTLANG - - (%TEXT;) --<Titre>Langue d'arrivée--

--Champ 25--

>

<!ELEMENT DELIVERY - - (%TEXT;)

• -<Titre>Mode de livraison demandé--
• -Si l'attribut RTN-TYPE = FAX, taper le numéro de télécopieur, si RTN-TYPE = E-MAIL, taper l'adresse de courrier électronique, si RDN-TYPE = MODEM, tapez le numéro du modem.--
• -Champs 26-34--

>

<!ELEMENT INCL - O EMPTY --<Titre>Pièces jointes?--

--Champs 36,37--

>

<!ELEMENT USE - O EMPTY --<Titre>Destination--

--Champs 38,39--

>

<!ELEMENT PREVREQ - - (REQ-NO, DATE)

• -<Titre>Numéro de demande précédent--
• -Si cette demande est une suite ou une modification d'une traduction antérieure, inscrire le numéro et la date de cette demande--
• -Champs 40,41--

>

<!ELEMENT REQ-NO - - (%TEXT;) --<Titre>Numéro de la demande--

--Champ 40--

>

<!ELEMENT DATE - - (%TEXT;) --<Titre>Date--

• -Taper AAMMJJ--
• -Champ 41--

>

<!ELEMENT SPEC-INSTR - - (DISKNUM?, (SOFTWARE , VERSION)?)

• -<Titre>Instructions spéciales--
• -Champs 42-48--

>

<!ELEMENT SOFTWARE - - (%TEXT;)

• -<Titre>Logiciel de traitement de texte utilisé--
• -Champ 47--

>

<!ELEMENT VERSION - - (%TEXT;)

• -<Titre>Version du logiciel utilisé--
• -Champ 48--

>

<!ELEMENT DISKNUM - - (%TEXT;)

• -<Titre>Nombre de disquettes présentées--
• -Champ 46--

>

<!ELEMENT AUTHORITY - - (NAME , POSTIT , SIGNATURE?)

• -<Titre>Fondé de pouvoirs de signature--
• -Champs 49,50,54--

>

<!ELEMENT SIGNATURE - - (%TEXT;) --<Titre>Signature--

--Champ 54--

>

<!ELEMENT NOPAGE - - (%TEXT;)

• -<Titre>Nombre de mots ou de pages à traduire-- ----
• -Champ 51--

>

<!ELEMENT CERT - O EMPTY --<Titre>Certification--

• -Cocher la case pour certifier que ce texte n'a pas déjà été traduit d'après l'ICIST --
• -Champ 52--

>

<!ELEMENT NAMELIB - - (%TEXT;)

• -<Titre>Nom du bibliothécaire du ministère-- ---
• -Champ 53--

>

<!ELEMENT DOC-TYPE - O EMPTY --<Titre>Nature du document--

--Champs 55-62--

>

<!ELEMENT RCV-DATE - - (%TEXT;) --<Titre>Reçu le--

• -Taper AAMMJJ--
• -Champ 63 --

>

<!ELEMENT PRIORITY - - EMPTY --<Titre>Priorité--

--Champs 64-68 --

>

<!ELEMENT REMARKS - - (LINE , (LINE , (LINE , (LINE , (LINE , LINE?)?)?)?)?) --<Titre>Observations--

--Champ 69 --

>

<!ELEMENT POLICY - - (Line, Line?) --<Titre>Conforme à la politique--

--Champ 70 --

>

<!ELEMENT COORD - - (NAME , SIGNATURE?) --<Titre>Information sur le coordonnateur--

--Champs 71,72 --

>

<!ELEMENT BUREAU-USE - - (TX-SEC-CLASS, TX-GEOG-CODE , TX-SRC-LANG , TX-TGT-LANG ,

RECEPTION , TX-TGT-DATE , SPEC-CODES , TX-RAT-PRTY ,

TX-TENT-WORD , TX-FINAL-WORD? , (TRANSLATION , FILENO ,

TX-NO-DOCS , CANCEL-DATE? , RETURN-DATE? , TRANSL? , REV? ,

TYPING? , PROOF?)? , RG-REQ-NO1) --<Title>BUREAU-USE--

• -Cet élément contient tous les éléments réservés au Bureau de la traduction.--
• -Champs 73-100--

>

<!ELEMENT TX-SEC-CLASS - - (%TEXT;) --<Titre>Cote de sécurité--

• -Réservé au Bureau de la traduction--
• -Champ 73 --

>

<!ELEMENT TX-GEOG-CODE - - (%TEXT;) --<Titre>Code géographique--

• -Réservé au Bureau de la traduction--
• -Champ 74 --

>

<!ELEMENT TX-SRC-LANG - - (%TEXT;) --<Titre>Code de langue de départ--

• -Réservé au Bureau de la traduction--
• -Champ 75 --

>

<!ELEMENT TX-TGT-LANG - - (%TEXT;) --<Titre>Code de la langue d'arrivée--

• -Réservé au Bureau de la traduction--
• -Champ 76 --

>

<!ELEMENT RECEPTION - - (UNIT , DATE) --<Titre>Reçu par--

• -Réservé au Bureau de la traduction--
• -Champ 77 --

>

<!ELEMENT UNIT - - (%TEXT;)

• -<Titre>Code d'unité du Bureau de la traduction--
• -Réservé au Bureau de la traduction--
• -Champ 78 --

>

<!ELEMENT TX-TGT-DATE - - (%TEXT;) --<Titre>Date cible de retour--

• -Réservé au Bureau de la traduction--
• -Champ 79 --

>

<!ELEMENT SPEC-CODES - - (TX-MAIN-SPEC1 , (TX-MAIN-SPEC2 ,

TX-MAIN-SPEC3?)?) --<Titre>Codes de spécialité--

• -Réservé au Bureau de la traduction--
• -Champs 80-82 --

>

<!ELEMENT TX-MAIN-SPEC1 - - (%TEXT;) --<Titre>Code de spécialité #1--

• -Réservé au Bureau de la traduction--
• -Champ 80 --

>

<!ELEMENT TX-MAIN-SPEC2 - - (%TEXT;) --<Titre>Code de spécialité #2--

• -Réservé au Bureau de la traduction--
• -Champ 81 --

>

<!ELEMENT TX-MAIN-SPEC3 - - (%TEXT;) --<Titre>Code de spécialité #3--

• -Réservé au Bureau de la traduction--
• -Champ 82 --

>

<!ELEMENT TX-RAT-PRTY - O EMPTY --<Titre>Priorité pondérée--

• -Réservé au Bureau de la traduction--
• -Champs 83-87 --

>

<!ELEMENT TX-TENT-WORD - - (%TEXT;)

• -<Titre>Nombre de mots provisoire--
• -Réservé au Bureau de la traduction--
• -Champ 88 --

>

<!ELEMENT TX-FINAL-WORD - - (%TEXT;) --<Titre>Nombre de mots définitif--

• -Réservé au Bureau de la traduction--
• -Champ 89 --

>

<!ELEMENT TRANSLATION - - (UNIT , DATE)

• -<Titre>Service de traduction et date de réception--
• -Réservé au Bureau de la traduction--
• -Champs 90,91 --

>

<!ELEMENT FILENO - - (%TEXT;)

• -<Titre>Référence du Bureau de la traduction--
• -Réservé au Bureau de la traduction--
• -Champ 92 --

>

<!ELEMENT TX-NO-DOCS - - (%TEXT;) --<Titre>Nombre de documents--

• -Réservé au Bureau de la traduction--
• -Champ 93 --

>

<!ELEMENT CANCEL-DATE - - (%TEXT;) --<Titre>Date d'annulation--

• -Réservé au Bureau de la traduction--
• -Champ 94 --

>

<!ELEMENT RETURN-DATE - - (%TEXT;)

• -<Titre>Date de retour au client--
• -Réservé au Bureau de la traduction--
• -Champ 95 --

>

<!ELEMENT TRANSL - - (LINE , LINE?) --<Titre>Commentaires du traducteur--

• -Réservé au Bureau de la traduction--
• -Champ 96 --

>

<!ELEMENT REV - - (LINE , LINE?) --<Titre>Commentaires concernant la révision--

• -Réservé au Bureau de la traduction--
• -Champ 97 --

>

<!ELEMENT TYPING - - (LINE , LINE?) --<Titre>Commentaires concernant la frappe--

• -Réservé au Bureau de la traduction--
• -Champ 98 --

>

<!ELEMENT PROOF - - (LINE , LINE?) --<Titre>Commentaires concernant la relecture--

• -Réservé au Bureau de la traduction--
• -Champ 99 --

>

<!ELEMENT RG-REQ-NO1 - - (%TEXT;)

• -<Titre>Numéro de la demande (bas de la page)--
• - Réservé au Bureau de la traduction--
• -Champ 78 --

>

<!ELEMENT RG-REQ-NO2 - - (%TEXT;)

• -<Titre>Numéro de la demande (haut de la page)--
• - Réservé au Bureau de la traduction--
• -Champ 101--

>

<!ELEMENT LINE - - (%TEXT;) --<Titre>Ligne d'entrée unique--

--Utilisé lorsqu'on peut se servir de lignes multiples d'entrée pour un élément particulier.--

>

<!ATTLIST COTESEC

CLASSIF (NONE , PROTECTA , PROTECTB , PROTECTC ,

CONFIDENTIAL , SECRET , TOPSECRET) #REQUIRED

--<Titre>Groupe de boutons radio de cote de sécurité--

>

<!ATTLIST NAME --<Titre>Nom de la personne--

MR-MS (MR , MS) #REQUIRED

• -<Titre>Groupe de boutons radio pour la sélection de M. ou Mme--
• -Groupe de boutons radio pour la sélection de M. ou Mme--

>

<!ATTLIST DELIVERY

RTN-TYPE (CALL , MAIL , FAX , E-MAIL , MODEM)

#REQUIRED

• -<Titre>Groupe de boutons radio pour le mode de livraison demandé--
• -Groupe de boutons radio pour la sélection du mode de livraison et de communication demandé--

>

<!ATTLIST INCL

ENCL (INC , NOTINC) #REQUIRED

• -<Titre>Groupe de boutons radio des pièces jointes--
• -Groupe de boutons radio pour indiquer si les documents sont joints au formulaire ou si seulement la liste des documents est incluse--

>

<!ATTLIST USE --<Titre>Material Use Checkboxes-

OUT %yesorno; #IMPLIED

• -<Titre>Case à cocher pour EXT--
• -Case à cocher pour indiquer si la documentation sera acheminée à l'extérieur du gouvernement--

WITHIN %yesorno; #IMPLIED

• -<Titre>Case à cocher pour INT--
• -Case à cocher pour indiquer que la documentation ne sera pas acheminée à l'extérieur du gouvernement--

>

<!ATTLIST SPEC-INSTR --<Titre>Cases à cocher pour les instructions--

TRCH %yesorno; #IMPLIED

• -<Titre>Ne traduire que les modifications indiquées--
• -Case à cocher pour préciser s'il faut traduire uniquement les modifications indiquées.--

DRAFT %yesorno; #IMPLIED

• -<Titre>Copie brouillon acceptable--
• -Case à cocher pour indiquer si une copie brouillon est acceptable.

SUMM %yesorno; #IMPLIED

• -<Titre>Résumer dans la langue d'arrivée--
• -Case à cocher pour indiquer s'il faut produire un résumé des documents.--

DISK %yesorno; #IMPLIED

• -<Titre>Utiliser disquettes ci-jointes--
• -Case à cocher pour indiquer si le traducteur doit utiliser les disquettes jointes.--

>

<!ATTLIST CERT

CERT %yesorno; #IMPLIED

• -<Titre>Case à cocher de certification--
• -Case servant à certifier que le texte n'a pas déjà été traduit d'après l'ICIST--

>

<!ATTLIST DOC-TYPE

DOC-TYPE (CORRES , CIRCULAR , JOBD , REPORT , AGENDA ,

MANUAL , PUBLICATION , OTHER) #REQUIRED

• -<Titre>Groupe de boutons radio de la nature du document--
• -Groupe de boutons radio indiquant la nature du document. Si la case AUTRE est cochée, taper des renseignements supplémentaires dans le champ OBSERVATIONS.--

>

<!ATTLIST PRIORITY

PRIORITY (1 , 2 , 3 , 4 , 5) #REQUIRED

• -<Titre>Groupe de boutons radio
• -Groupe de boutons radio pour indiquer la priorité--

>

<!ATTLIST TX-RAT-PRTY

PRIORITY (1 , 2 , 3 , 4 , 5) #REQUIRED

• -<Titre>Groupe de boutons radio de code de priorité--
• -Groupe de boutons radio pour indiquer la priorité précisée par le coordonnateur.--

>

<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN"

--<Titre>ISOlat1--

>

<!ENTITY % ISOgrk3 PUBLIC "ISO 8879-1986//ENTITIES Greek Symbols//EN"

--<Titre>ISOgrk3--

>

<!ENTITY % ISOnum PUBLIC

"ISO 8879-1986//ENTITIES Numeric and Special Graphic//EN"

--<Titre>ISOnum--

>

<!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN"

--<Titre>ISOpub--

>

<!ENTITY % ISOtech PUBLIC

"ISO 8879-1986//ENTITIES General Technical//EN"

--<Titre>ISOtech--

>

%ISOgrk3;

%ISOlat1;

%ISOnum;

%ISOpub;

%ISOtech;

]>

Instance de demande de traduction

<!DOCTYPE TRANSLAT PUBLIC "-//CDN-GOV//DTD TRANSLATION E-FORM//EN" "translat.dtd">

<TRANSLAT><HEADER><RG-REQ-NO2>1019987</RG-REQ-NO2>

<COTESEC CLASSIF="NONE"></HEADER>

<ORIGIN-USE><DEPART><LINE>Natural Resources Canada</LINE>

<TX-CODE>333</TX-CODE></DEPART>

<BRANCH><LINE>Mines</LINE>

<TX-BRANCH>55</TX-BRANCH></BRANCH>

<DIVISION><LINE>Longlac</LINE>

<TX-DIVISION>77</TX-DIVISION></DIVISION>

<TX-ORIG-FILE>123456789</TX-ORIG-FILE>

<ORIGIN><NAME MR-MS="MR">Andr&eacute; Moore</NAME>

<POSTIT>Executive Assistant</POSTIT>

<TELNO>613 993-9998</TELNO>

<ADDR><LINE>580 Booth Street</LINE>

<LINE>P.O. Box 10, Ottawa, ON</LINE>

<POSTCODE>K1P5G8</POSTCODE></ADDR></ORIGIN>

<AUTHOR><NAME MR-MS="MR">Robert Burns</NAME>

<TELNO>708 456-8765</TELNO></AUTHOR>

<TX-DOC-TITLE>How to SGML E-forms</TX-DOC-TITLE>

<TX-SUB-DATE>960316</TX-SUB-DATE>

<TX-WISH-DATE><DATE>960512</DATE>

<TGHOUR>1300</TGHOUR></TX-WISH-DATE>

<SRCLANG>English</SRCLANG>

<TGTLANG>French</TGTLANG>

<DELIVERY RTN-TYPE="E-MAIL">larry@idc.com</DELIVERY>

<INCL ENCL="NOTINC">

<USE OUT="1" WITHIN="1">

<SPEC-INSTR DRAFT="1" DISK="1"></SPEC-INSTR>

<AUTHORITY><NAME MR-MS="MS">T. Brown</NAME>

<POSTIT>Supervisor</POSTIT>

<SIGNATURE>T. Brown</SIGNATURE></AUTHORITY>

<NOPAGE>120</NOPAGE>

<CERT CERT="1">

<NAMELIB>Jim Jones</NAMELIB></ORIGIN-USE>

<COORD-USE><DOC-TYPE DOC-TYPE="PUBLICATION">

<RCV-DATE>960318</RCV-DATE>

<PRIORITY PRIORITY="4"></PRIORITY>

<POLICY><LINE>TBITS Standard 123</LINE></POLICY>

<COORD><NAME MR-MS="MS">M. Rabinski</NAME>

<SIGNATURE>M. Rabinski</SIGNATURE></COORD></COORD-USE>

<BUREAU-USE><TX-SEC-CLASS>AA</TX-SEC-CLASS>

<TX-GEOG-CODE>BB</TX-GEOG-CODE>

<TX-SRC-LANG>01</TX-SRC-LANG>

<TX-TGT-LANG>02</TX-TGT-LANG>

<RECEPTION><UNIT>345</UNIT>

<DATE>960320</DATE></RECEPTION>

<TX-TGT-DATE>960430</TX-TGT-DATE>

<SPEC-CODES><TX-MAIN-SPEC1>123456</TX-MAIN-SPEC1>

<TX-MAIN-SPEC2>234567</TX-MAIN-SPEC2>

<TX-MAIN-SPEC3>345678</TX-MAIN-SPEC3></SPEC-CODES>

<TX-RAT-PRTY PRIORITY="4">

<TX-TENT-WORD>120</TX-TENT-WORD>

<TX-FINAL-WORD>160</TX-FINAL-WORD>

<TRANSLATION><UNIT>889</UNIT>

<DATE>960427</DATE></TRANSLATION>

<FILENO>987654321</FILENO>

<TX-NO-DOCS>1</TX-NO-DOCS>

<RETURN-DATE>960429</RETURN-DATE>

<TRANSL><LINE>Everything went well.</LINE></TRANSL>

<REV><LINE>Not quite.</LINE>

<LINE>Could be better</LINE></REV>

<TYPING><LINE>ok</LINE></TYPING>

<PROOF><LINE>Good here</LINE></PROOF>

<RG-REQ-NO1>7869875</RG-REQ-NO1></BUREAU-USE></TRANSLAT>

Annexe D : PARTICIPANTS - Projet pilote de normalisation de l'interface

des formulaires électroniques

Participant Organisme

Ed Buchinski Secrétariat du Conseil du Trésor

Carol Chambers Ministère de la Défense nationale

Neal Davies JetForm Corporation

Robert Dupuis Travaux publics et Services gouvernementaux Canada

Ernie Isaak JetForm Corporation

Stan Jaknunas Ministère de la Défense nationale

Norman LeCouvie Novell Canada Ltd.

Neil Levette Office national de l'énergie

Jim Lowe Travaux publics et Services gouvernementaux Canada

Gavin McKenzie JetForm Corporation

Dave Milne Ministère de la Défense nationale

David Nikkel JetForm Corporation

Ernie O'Dell Ministère de la Défense nationale

Larry Osipenko InfoDesign Corporation

Robert Rouleau Ressources naturelles Canada

Tim Sage Craig Technologies

Sonia Schindler Travaux publics et Services gouvernementaux Canada

Lothar Wegner Craig Technologies

Observateur Organisme

Bruce Catley Travaux publics et Services gouvernementaux Canada

Angèle Gosselin Travaux publics et Services gouvernementaux Canada

John McDonald Archives nationales du Canada

Kent McPhee Shana Corporation

Wayne Malkin Shana Corporation

Don Murphy Shana Corporation

Mike Tardif Secrétariat du Conseil du Trésor

Russell Thomas Conseil national de recherches

Michel Vulpe Infrastructures for Information