Introduction


Dans la première phase du projet, parallèlement à la mise en place d’un processus communautaire, nous travaillons à l’élaboration d’un cahier des charges, en collaboration avec des institutions publiques, les entreprises intéressées et des citoyens.

Lors de notre travail, nous avons eu la chance de découvrir OpenOffice.org car le format de fichier OOo semble répondre à la plupart des besoins que nous avons identifiés pour le moment.

Ce qui lui manque, selon nous, est un modèle de méta-données plus sophistiqué qui permettrait aux systèmes automatiques de gestion électronique de documents, de gestion de tâches ou d’archivage de traiter les documents et aussi les contenus spécifiques aux applications comme le champ adresse, le numéro de commande etc..

Concernant la nécessité de structures sémantiques, nous partageons l’opinion des gens de Linux Information Systems AG qui parvinrent à des résultats similaires dans leur étude déjà débattue sur OpenOffice.org.

L’implémentation d’un modèle de méta-données mènerait à un nouveau paradigme pour le traitement de l’information contenue dans les documents, par les organisations et dans plusieurs situations de communication comme p. ex. le B2B (entreprise à entreprise), B2C (entreprise à client), G2C (gouvernement à citoyen), G2G (gouvernement à gouvernement) etc..

Grâce à cette technologie, une institution publique pourrait, par exemple, mettre à disposition des formulaires d’inscription qui seraient téléchargés par les citoyens et renvoyés une fois complétés. Le document retourné serait identifié automatiquement comme un formulaire d’inscription par un système de gestion des tâches et la tâche appropriée serait alors initiée.

Même sur l’ordinateur de bureau d’un citoyen, un nouveau paradigme d’enregistrement de documents serait introduit : il suffirait à l’utilisateur d’appuyer sur le bouton ‘enregistrer’ sans avoir à sélectionner un répertoire ou spécifier un nom de fichier.

Dans la suite bureautique (OOo), le document serait enregistré selon ce qu’il déclare être : un formulaire d’inscription pour ‘telle chose’, complété par ‘untel’ le ‘tant’, envoyé à ‘untel’ etc. Les documents enregistrés pourraient ensuite être retrouvés en précisant ces mêmes attributs.


Proposition


Extension du format de fichier d’OOo.
Nous proposons d’implémenter dans le format de fichier d’OOo la possibilité d’enregistrer du contenu arbitraire, structuré sémantiquement, spécifié par des schémas XML .
Le modèle de méta-données sous-jacent devrait être hiérarchique et orienté objet. Ce qui signifie qu’à partir d’un document de base qui contient seulement des informations rudimentaires comme la classe de document, l’auteur, la date de création, la version du format de fichier etc., on pourrait dériver des classes de documents plus complexes comme des formulaires d’inscription, des bons de livraisons, des factures etc.
Tout document à l’intérieur de cette structure hériterait de tous les attributs de son prédécesseur.

Afin de préciser clairement nos intentions, nous insistons sur le fait que la spécification du contenu ne fait pas partie de notre proposition. Notre objet réside dans la possibilité pour le format de fichier d’OOo de contenir du contenu arbitraire décrit sémantiquement par des schémas XML.
Les informations sur les contenus spécifiques aux applixations peuvent être tirés d’autres spécifications comme EDIFACT, ebXML, openTRANS, DOMEA etc..

Veuillez vous reporter à www.1dok.org/fr/ pour une illustration de la proposition de modèle de méta-données 1dok.

Enregistrement des documents
L’enregistrement des documents pourrait être effectué de façon associative, ainsi qu’il est décrit dans l’introduction.

Edition des formulaires
OOo pourrait offrir une boîte à outils de contrôles spécialisés dans l’introduction et l ‘édition de données, en fonction des schémas XML.

Si, par exemple OOo trouvait une définition de type d’élément pour un ISBN dans un schéma XML, il pourrait offrir le champ d’entrée de texte (spécialisé) correspondant à l’ISBN dans la boîte à outils contenant les contrôles de formulaire.



La définition du type d’élément pourrait être dérivée du type de base xsd :string et pourrait être spécialisée au moyen d’une expression standard qui définit la structure syntaxique pour un ISBN comme ci-dessous :



En plaçant le champ ISBN sur le formulaire,





un élément XML au nom correspondant serait généré et placé quelque part dans le document, par exemple dans le meta.xml



ou, comme proposé par les gens de Linux Information Systems AG dans le content.xml lui-même.

En remplissant le formulaire, les données introduites seraient validées en utilisant les restrictions définies par le schéma XML et stockées dans la structure de données XML correspondante, où elles pourraient être lues par n’importe quelle machine.

Salutations

Bernd Schuster
1dok.org