Guides d'implémentation accompagnant le schéma >> Guide du schéma XML DAPA
| Date (created) : | 2004 -01 -07 |
| Date (modified) : | 2004-06-24 |
| Creator : | Bougoüin, , Christine |
| Description : |
Présentation du schéma SDAPA dans sa philosophie et son application. Cette présentation se veut volontairement générique et indépendante du contexte DAPA. |
Table des matières
Le schéma SDAPA est, par définition, un schéma généraliste sans spécialité. Il est donc particulièrement ambitieux dans son application. D'un usage principalement documentaire, il englobe plusieurs standards internationaux, notamment Dublin Core<1> et Docbook<2>.
Ce schéma se destine aux organisations souhaitant donner une forme XML à des informations rédactionnelles et des données. Contrairement à un schéma spécialisé pour des données, il est généraliste et adapté à la rédaction humaine, depuis la structure d'un article jusqu'à celle d'un livre. Et contrairement à un schéma purement rédactionnel, il ne se destine pas seulement à la publication (écran ou imprimée) ; il est aussi structuré pour satisfaire des applications automatiques comme la génération d'index.
Qu'est-ce qu'un schéma XML?
Il s'agit de la grammaire d'un langage qui définit la structure des documents XML qui s'y référent. Un schéma XML décrit principalement :
les éléments et les attributs qui peuvent apparaître dans un document
quels éléments peut contenir un élément, soit la définition des éléments-fils d'un élément
l'ordre d'apparition et la cardinalité des sous-éléments d'un élément
le modèle de contenu des éléments : uniquement textuel, seulement des sous-éléments, mixte ou encore vide
le type de données contenues par un élément ou un attribut
les valeurs par défaut ou obligatoires des éléments et des attributs, par exemple la définition de listes de valeurs possibles
Mais avant toute chose, s'il est question d'un schéma, c'est que le choix d'adopter XML a déjà été fait. En effet, la réalisation de ce schéma intervient dans le cadre de la mise en place du dossier électronique au sein de la DAPA, et que ces dossiers électroniques sont au format XML.
La norme XML<3> est particulièrement adaptée pour définir des documents structurés, et ce pour deux raisons principales :
le modèle de données est hiérarchique, ce qui est également le cas des documents textuels (notion de plan, table des matières), et qui peut s'appliquer dans la plupart des données
les documents XML peuvent être validés selon une grammaire, un schéma XML dans le cadre de ce projet, permettant de définir et donc de limiter les structures possibles
Dans les faits, la norme XML définit très peu de choses, mais au moins cette idée essentielle : toute information, qu'elle soit de type documentaire ou données, doit pouvoir s'exprimer sans perte dans un format texte et demeurer lisible par l'humain.
Les documents XML sont des documents qui utilisent des balises compréhensibles par les humains, pour autant que l'on connaisse la langue des balises et le sens des mots utilisés. De plus, les documents XML sont des fichiers texte ; et donc pas stockés selon un format propriétaire. Ces fichiers sont donc lisibles par n'importe quelle configuration informatique. Ils sont modifiables par un simple éditeur de texte.
La structuration du texte est donc la principale caractéristique de XML. Il s'agit de définir un format qui explique la nature des informations écrites, sans en imposer la présentation. Ceci est fait par les schémas (ou DTD) de documents structurés. Ceux-ci définissent les éléments sémantiques qu'une communauté souhaite distinguer (phrase, bloc, liste, table, divisions, structures).
La distinction entre présentation et structuration sémantique est la principale caractéristique de l'utilisation d'XML. Or il s'agit d'une notion nouvelle pour un habitué des traitements de texte. Par exemple : dire qu'une phrase est une citation est une précision sémantique tandis que l'italique n'est qu'un exemple de restitution. Or justement dans un document XML, il est possible de faire cette distinction. XML étant un langage qui permet d'inventer de nouvelles balises pour isoler des informations élémentaires ou agrégats d'informations élémentaires d'un contexte, le choix efficient du nom des balises (en général le nom des balises traduit la nature sémantique de son contenu) contribue à cet enrichissement sémantique. En d'autres termes, les noms des balises reflètent la nature des informations qu'elles contiennent ce qui rend le schéma ou la DTD plus clair. Une grammaire XML, schéma ou DTD, manifeste sa spécificité en identifiant les sémantiques qui concernent un domaine d'application.
Le fait de distinguer la présentation de la structure autorise la pluralité des formats de sortie : un même document XML peut prendre une infinité d'"apparences". Par exemple, pour une bibliographie : sans toucher aux données, il est possible d'obtenir de multiples tris des références bibliographiques (par ordre alphabétique des auteurs, des titres), différentes mises en forme (titre en gras ou souligné ou en italique suivant le style de formatage appliqué).
XML permet donc de définir des formats de documents. Il s'applique à toutes les problématiques documentaires aussi s'agit-il d'une bonne solution dans le cas où l'on doit gérer des documents de natures diverses (image, notice, article, dossier). Il est notamment reconnu pour être un bon modèle pour l'échange de données entre des systèmes plus ou moins hétérogènes.
En conclusion :
XML est un format normalisé
Les documents XML sont indépendants des plates-formes, systèmes ou logiciels
Les informations sont autodécrites
Les documents sont lisibles par l'humain
Il s'agit d'expliquer les principes qui ont régi la conception du schéma et qui en explique sa forme.
Ce schéma constitue le principal "livrable" d'un projet de modélisation de l'information issue de plusieurs domaines d'activité en relation avec le patrimoine. Au départ, plusieurs schémas étaient prévus mais il s'est avéré que les ressemblances étaient plus nombreuses que les particularités des différents domaines. Finalement, un seul schéma, capable de prendre en charge les spécificités de chacun a été réalisé, ce qui étaient la meilleure solution pour disposer d'un modèle de données d'échange.
Dans un premier temps, les principaux standards ont été passés au crible pour voir si l'un d'eux ne pourrait pas convenir. Finalement, aucun ne pouvant répondre à tous les besoins exprimés, il a été décidé d'en élaborer un. Néanmoins, pour ne pas réinventer la roue et pouvoir profiter des développements d'une communauté, le plus convaincant des standards a été choisi comme modèle de base : il s'agit de Docbook<4>.
Langage du schéma
Pour répondre aux nouveaux développements (espaces de noms) de XML qu'il a édicté, le W3C<5> se devait de proposer un langage de modélisation en XML ; il s'agit de XML Schema<6>. Les premières propositions qui en fondent le style actuel proviennent de l'industrie (dont Microsoft). Cela suffit à expliquer l'excellent support chez les éditeurs, mais aussi les critiques circulant dans les milieux de l'informatique documentaire libre. Cependant la syntaxe XML est très élaborée et permet un typage de chaque noeud (listes de types prédéfinis ou définissables par expressions régulières et algébriques) ce qui pousse très loin la modularité. Mais il s'agit surtout d'un langage d'écriture de schémas répandu et pour lequel on peut disposer d'un nombre important d'outils.
Quelques principes de base ont régi l'élaboration du schéma :
Le schéma doit être simple d'utilisation et permettre l'intégration d'autres espaces de noms, comme par exemple GML<7> pour les informations géodésiques.
Choisir une structuration suffisante pour rester proche du standard de base choisi et pouvoir utiliser les ressources libres et internationales.
Limiter le nombre de références à des schémas extérieurs. En fait le schéma SDAPA est un multi-schéma dans la référence (il se réfère à un certain nombre de schémas standards dont Dublin Core et Docbook) mais pas dans la définition (il n'y a pas d'insertion d'un autre schéma dans la définition même de SDAPA, seulement des copies de parties de schémas pour pouvoir bénéficier des outils et applications développés par la communauté, à l'exception toutefois du schéma GML<8>).***
Métadonnées : le schéma doit couvrir entre autres la gestion et l'édition de documents, l'échange d'informations. Ceci implique donc de pouvoir identifier et suivre un document tout au long d'une chaîne documentaire d'où l'importance des métadonnées. De plus, les exportations de métadonnées Dublin Core sont destinées à être de plus en plus courantes, surtout avec la diffusion du protocole OAI<9>. C'est une des raisons de l'usage des éléments Dublin Core dans le schéma pour traiter les métadonnées.
Permettre l'échange de données et même uniquement de
métadonnées d'où l'importance du bloc info.
Offrir une structuration sémantique détaillée, notamment pour des notions importantes dans le contexte d'utilisation : information géographique, adresse, information biographique...
Respecter autant que possible la compatibilité avec les standards ce qui se traduit notamment par la reprise des noms d'éléments.
Permettre l'importation et l'exportation de données.
L'importation de données plus ou loin structurées ou dont la
structuration n'est pas perceptible par une machine doit
aussi être prise en compte. Il existe des cas où le format
cible ne pourra pas être aussi structuré que l'on pourrait
le souhaiter. C'est la raison de la présence de l'élément
unqualified
(offrir une structuration minimale).
Se baser autant que possible sur des standards éprouvés ; Docbook<10> choisi comme schéma de base, Dublin Core<11> pour les métadonnées, HTML<12> pour les tableaux.
Le schéma SDAPA s'inspire largement de ce qui existe déjà dans des standards. Dans certains cas, il corrige des défauts ou des manques. En général, il apporte surtout une structuration de l'information plus poussée qui répond plus précisément aux besoins documentaires. Ainsi dans le cadre des métadonnées, aux 15 éléments de base du Dublin Core<13>, optionnels et répétables, non ordonnés, une structuration supplémentaire est ajoutée mais sans modifier le principe de base du Dublin Core. En effet, la pratique et l'usage du Dublin Core dans des domaines variés ont prouvé que ces 15 éléments suffisent à décrire un objet documentaire. L'apport d'une structuration supplémentaire offre toutefois des possibilités de traitement plus larges.
Finalement, le schéma SDAPA intègre les principales notions décrites dans les standards.
Au cours de l'élaboration du schéma, un certain nombre de choix se sont imposés.
Hiérarchie finie et hiérarchie récursive
Dans le schéma SDAPA, deux modes de hiérarchie se
retrouvent. D'abord la hiérarchie finie au niveau sémantique
et au plus haut niveau hiérarchique du document :
définition par le nom de l'élément-racine du type de document
traité. Puis la hiérarchie récursive, dans ce cas le niveau
hiérarchique se déduit de l'emboîtement des éléments ;
par exemple, la numérotation des parties d'un article, le
plan, se déduit de l'imbrication des éléments section.
Noms des éléments
L'expérience XML a montré que certains noms standards se sont imposés, même s'ils sont en "langue internationale". Dans un souci de compatibilité avec les standards du domaine et dans la mesure où les noms sont significatifs de l'usage de l'élément, les noms des éléments sont en anglais et autant que possible identiques à ceux utilisés dans un standard ou un autre. En fait, peu de noms d'éléments ont été créés. Dans leur grande majorité, les noms des éléments sont faciles à comprendre, y compris pour une personne peu familière avec la langue anglaise, au moins pour les éléments les plus courants. De plus, le schéma dispose d'une documentation qui éclaire l'usage des éléments par une définition et des exemples. Il faut aussi se rappeler que l'édition de documents XML se fait en général dans un éditeur XML qui masque en partie le code et suggère les éléments à insérer. Le choix de noms significatifs pour les éléments est un principe qui explique en partie le succès de Docbook<14> en tant que standard rédactionnel. Ce principe traduit d'ailleurs parfaitement l'intention qu'un document XML se définisse par lui-même et que contenu et structure restent humainement lisibles.
Reprise de parties de schéma
Certains modèles éprouvés par l'expérience et pour lesquels des outils sont disponibles pour l'exploitation et la représentation sont repris dans le schéma SDAPA. Il s'agit des éléments pour les tableaux tirés de HTML<15>, du principe des index extrait de Docbook<16>, éventuellement du recours à GML<17> pour traiter les coordonnées géodésiques.
Contenu mixte
Un contenu mixte est un contenu qui mêle du texte et des
sous-éléments, sans contrôle possible sur la position du texte
par rapport à celles des sous-éléments. Ce dernier point fait
que l'on peut très vite arriver à des situations structurelles
difficilement exploitables. Aussi, dans le schéma SDAPA, le
recours au contenu mixte a été limité au traitement des
éléments de niveau phrase, soit les éléments qui viennent
caractériser des chaînes de caractères à l'intérieur même du
texte tels que emphasis, sup, sub, etc.
Que contient le schéma ? Que permet-il de faire ?
Le schéma doit répondre à des besoins rédactionnels et documentaires. En dehors des éléments proprement rédactionnels, la notion importante à traiter est celle des relations. Afin que le passage au dossier électronique puisse être exploité au mieux, le schéma dispose des éléments suffisants pour gérer les relations mais ceux-ci doivent, pour être effectivement fonctionnels, être accompagnés de règles de bonne pratique. Car les liens effectifs ne sont créés qu'à l'issue d'un traitement, en général l'application d'une feuille de style. Les modalités d'application demeurent à définir par le contexte d'utilisation.
Tout d'abord, le schéma SDAPA permet de créer des documents structurés. Ces derniers, de ce fait, peuvent avoir ensuite plusieurs restitutions, XML (voir la source XML de ce document), HTML (la version que vous consultez dans votre navigateur), PDF, CSV, etc. sans qu'il soit nécessaire de toucher à leur contenu. En dehors des particularités qui découlent de la documentation structurée, voici les principales caractéristiques du schéma SDAPA :
Tous les éléments "significatifs" peuvent être élément
racine : or l'élément racine définit le document XML
qu'il introduit. Ainsi une notice descriptive en SDAPA
commence par record, une fiche de personnes
par person, une
liste de références bibliographiques par bibliography...
Omniprésence des métadonnées : il est toujours
possible d'ajouter de l'information complémentaire pour les
éléments significatifs, le bloc info est en général
facultatif.
Possibilité de faire des liens internes et externes : exemple d'utilisation, on parle d'une personne dans un paragraphe, il est possible de baliser son nom et de le lier à sa fiche biographique ou encore de la renseigner dans le document même. Ainsi tous les documents intervenants dans une même chaîne documentaire peuvent être reliés.
Eléments de navigation : index, bibliographie, lien, note. A partir de la structure d'un document, il est possible de construire automatiquement une table des matières, un index...
Tous les termes "balisés" peuvent bénéficier d'un traitement particulier. Ainsi l'information géographique dûment renseignée peut permettre la localisation sur une carte. Il en est de même de la réalisation d'index de noms de personnes, de lieux géographiques, de dates, extraction des illustrations, réalisation de chronologie automatique qui ne peuvent exister que si les éléments ont été "identifiés" par un balisage sémantique.
Enrichissement sémantique : le schéma SDAPA permet de préciser dans le texte de quelle information il est question pour des fins de traitement automatique, notamment la construction d'index des noms de personnes, de lieux géographiques...
Extraction d'informations pour réaliser par exemple un nouveau document : index des illustrations
Exportation et importation d'informations. Le schéma a
pris en compte les possibilités d'importation de données
contenues dans une base de données. Ainsi est-il possible
d'importer un carnet d'adresses, une base de données de
notices descriptives... Le schéma permet aussi de garder une
trace du champ d'origine grâce à l'attribut remap, champ dont provient le
contenu de l'élément dans le cas d'une exportation, ou
d'indiquer le champ-cible dans le cas d'une
importation.
Le schéma SDAPA est accompagné d'une documentation, consultable en version HTML. Celle-ci présente, en version navigable générée automatiquement, les annotations codées dans le fichier source du schéma. Elle expose l'ensemble des éléments, groupes (regroupements sémantiques d'éléments) et attributs définis dans la grammaire. Ceux-ci sont accessibles par le biais d'index.
A chaque élément correspond une page HTML qui donne les informations suivantes :
son nom
une courte définition
les références
un ou des exemple(s) d'utilisation
dans quels éléments il peut apparaître ou dans le cas d'un attribut les éléments qui l'acceptent, ses parents
les éléments que l'on retrouve au même niveau, ses frères
son modèle de contenu (i.e. les éléments qu'il peut contenir, leur ordre et cardinalité), ses enfants
ses attributs
l'extrait XML du code source où cette information est codée
Chaque nom d'élément ou d'attribut mentionné est un lien hypertexte qui pointe vers la définition de celui-ci.
En plus de la documentation, il convient d'insister sur certains éléments et attributs, notamment ceux qui sont obligatoires.
le bloc info qui, dans ce schéma à
vocation rédactionnelle avec une facette documentaire,
constitue un élément important peut être présent quasiment
partout
certaines métadonnées peuvent être extraites du bloc
info pour
signifier que dans ce cas elles sont plus particulièrement
intéressantes. Il s'agit, par exemple, de title obligatoire sous article. Cette
pratique s'accorde avec le côté rédactionnel du schéma avec
un fort support de métadonnées Dublin Core. Autre exemple,
event pour
lequel les éléments minimaux susceptibles de définir un
événement sont en dehors du bloc info. Faut-il répéter cette
information dans le bloc info ?
l'élément unqualified offre une
alternative à une qualification à outrance. D'autant plus
que dans certains cas, on ne dispose pas d'information
suffisante pour appliquer une qualification, notamment lors
d'une importation ou de la reprise d'existant plus ou moins
structuré. Cet élément permet aussi de réduire le recours au
contenu mixte. Le choix consiste à qualifier plus
précisément ou non.
l'attribut role des éléments source, relation et
link est
obligatoire. Cela signifie que ces éléments doivent toujours
être qualifiés.
Bien que le schéma n'impose pas grand chose et en permette beaucoup, certains éléments sont obligatoires :
title sous book,
article, chapter,
section, summary,
part,
part-index,
part-bibliography,
part-contents,
part-summary,
part-glossary,
example, figure
title, para
sous formalpara
orgname sous organization
role pour relation,
source,
link :
une relation entre deux ressources doit être
qualifiée.
Dans beaucoup d'autres cas, un choix entre des éléments
est obligatoire et impose un niveau de qualification (ou de non
qualification avec l'élément unqualified)
supplémentaire.
L'une des caractéristiques principales du schéma est d'être généraliste aussi au niveau du type des données ; peu de contraintes ont été mises dans le schéma lui-même. De ce fait, peu d'éléments voient leur contenu contraint par un type de données spécifiques prédéfinis dans la norme XML Schema. Les seules contraintes sur les types de données sont :
Le schéma SDAPA est basé sur deux modèles standards
Docbook<18> et
Dublin
Core<19>. Or ce dernier est un modèle descriptif pour les
métadonnées. Dans le schéma, il est utilisé pour encoder les
métadonnées générales ou particulières (élément info) et pour les
enregistrements de métadonnées (élément record).
Pour justifier le double niveau de métadonnées que l'on
peut retrouver lorsque l'on traite un enregistrement, soit les
éléments Dublin Core enfants de record et le bloc info de record, prenons le cas d'une
date :
L'élément date est déjà sémantiquement
significatif, c'est-à-dire qu'il indique précisément la
nature de son contenu qu'il est cependant possible de
structurer plus précisément (year, month...).
Dans le contexte d'un enregistrement de type bibliographique, une date indique généralement la date de publication. Le schéma permet évidemment cette précision mais pas uniquement, on peut qualifier d'autres types de dates avec des qualifiants pour différencier une date de création, de copyright... Il s'agit d'établir une liste d'autorité des types de dates susceptibles d'intervenir dans le processus d'affaires.
Cependant, sur une photographie de 1943, reproduite en
1984, une notice peut être créée en 2001, et modifiée en
2003. 2001 et 2003 sont des informations utiles, mais n'ont
pas du tout le même statut que 1943 et 1984. Les premières
se rapportent à la notice descriptive tandis que les
secondes concernent l'objet décrit. Ainsi la date de
création d'une notice tient-elle de la métadonnée relative à
la notice, elle apparaît donc dans un bloc info.
Le bloc info est un élément essentiel
du schéma ; il offre la possibilité d'une description
documentaire à un autre niveau (il s'agit de données sur les
données et non sur la ressource décrite elle-même). Il permet
notamment de donner des informations de gestion telles que la
date à laquelle a été créé le document ou son auteur. Il
intervient surtout au niveau des documents rédactionnels. Pour
les ressources documentaires, il rassemble les informations
sur la notice descriptive et non sur la ressource décrite. Ce
bloc se retrouve dans le schéma au niveau de presque tous les
éléments structurellement significatifs. Il se révèle très
intéressant dans le cas d'un document rédigé par plusieurs
auteurs à différentes périodes. Il est alors possible de
préciser pour chacune des sections du documents quel est
l'auteur et quelle est la date de rédaction.
Il ne s'agit pas de spéculer à plaisir sur le "méta
méta", la récursion s'arrête là. Et de plus, un bloc info pourrait éventuellement
être renseigné automatiquement par une application. Dans
l'esprit, l'export d'une notice peut se faire sans ce bloc,
laissant le système qui importe générer ses propres
informations système.
Il n'est évidemment pas question de détailler ici tous les usages possibles des métadonnées mais juste de préciser quelques bonnes pratiques. Cette précision s'impose vue l'importance des métadonnées. En effet, il est important de prendre conscience de ce que peut apporter l'usage intelligent des métadonnées. Ainsi dans une chaîne documentaire ne souhaiterait-on pas connaître les informations minimales sur tous les documents intervenant. Sans oublier que le fait d'utiliser des métadonnées permet de disposer d'un minimum d'informations sur chaque document, informations permettant d'identifier chacun des documents, par exemple dans une liste de résultats. Cette perspective permet aussi d'envisager des échanges de métadonnées, pourquoi pas selon le protocole OAI for Metadata Harvesting<20>.
Pour un bon usage du schéma, un certain nombre de listes d'autorité devraient être définies. Le schéma se voulant généraliste et indépendant de tout environnement documentaire, seules quelques listes généralistes ont été définies dans le schéma lui-même.
Cette décision a été motivée par les arguments suivants :
caractéristique généraliste du schéma
vocation de modèle d'échange du schéma entre des environnements diverses ; il aurait donc fallu que les listes d'autorité tiennent compte de cette variabilité d'environnement d'utilisation
support limité des listes d'autorité ouvertes par les outils XML or dans un contexte généraliste, il est impensable de prévoir autre chose que des listes ouvertes
même si le choix de listes avait été fait, quelles listes choisir ?
Le schéma ne contient donc aucune liste d'autorité. Mais avant d'avoir pris cette décision, un certain nombre de listes avaient été prévues, et celles-ci peuvent servir de base à l'établissement de lexiques personnels. En notant qu'il peut être intéressant de demeurer proche de standards internationaux.
attribut role de date : xs:Name ;
created, valid, available, issued, modified, accepted,
submitted, copyrighted ; completed, due, start, end,
stamp ; birth, death, active
qualifiants pour l'attribut role de relation et de source :
xs:Name ; isVersionOf, hasVersion, isReplacedBy,
replaces, isRequiredBy, requires, isPartOf, hasPart,
isReferencedBy, references, isFormatOf, hasFormat,
conformsTo => liste des qualifiants du Dublin
Core
valeurs pour lang : fr, en,ar, it, de,
fre
role de description :
xs:Name ; history, contents, index, note, howto,
inscription, abstract
scheme de identifier :
xs:string ; URI, ISBN, ISSN, DOI, number
scheme de height, width : xs:string ;
px, mm, cm, in, ft, m, km
role de contact, email, fax, phone : xs:string ;
home, work, pref
scheme de resolution :
xs:string ; dpi
role de markup : xs:string ;
element, attribute, attvalue, entity
role de resource : xs:string ;
serial, monographic, analytic, graphic, archive, event,
work, visual
role de organization :
xs:string ; gov, org, com
value de support : canvas, bristol
board, cardboard, glass, synthetics, skins, textiles,
metal, paper, plaster, hardboard, porcelain, stone, wood,
unknown, mixed ; xs:string
value de technique : pencil,
graphite, colour pencil, india ink, lavierung India ink,
coal, chalk, black chalk, sanguine, water colour, tempera,
gouache, pastel, felt-tip pen, stain, crayon, sepia,
writing ink, casein, golding, encaustic, acrylics,
collage, silver point, air brush, mixed ; woodcut,
chiaroscuro woodcut, white-line woodcut, camaiu,
heliogravure, chromolithography, lino-cut, etching,
lithography, photolithography, zincography, algraphy,
aquatint, reservage, vernis mou, engraving, engraving in
the crayon manner, burin engraving, drypoint, mezzotinta,
monotype, silkscreen, steel engraving, computer graphics,
photocopying, mixed ; xs:string ;
Le schéma laisse aussi une marge d'action pour les personnalisations.
attribut class, aucune consigne
d'utilisation n'est associée à cet attribut qui par
conséquent constitue une sorte d'attribut "personnalisable"
sans sémantique particulière.
attribut css pour préciser des
propriétés css de restitution
ajout d'attributs non définis dans le schéma ; en effet, le schéma autorise les éléments qui ont des attributs à accepter n'importe quel attribut (any attribute)
Les possibilités du schéma SDAPA dépendent en partie de l'usage que l'on en fait. En effet, seuls les éléments balisés peuvent être exploités par la suite. Il faut donc une volonté de la personne chargée d'éditer les documents. Une des clés de réussite est de rendre l'édition des documents, soit l'application du schéma, la plus transparente et la plus simple possible. Plus l'insertion des balises sera simple, plus leur usage se répandra (voir le succès des logiciels de traitement de texte). En dehors du schéma, il faut donc penser le paramétrage de l'éditeur XML et le développement de feuilles de style.
Le schéma contient plusieurs éléments pour contrôler le degré de diffusibilité des informations susceptible de répondre aux besoins de confidentialité d'un environnement d'application.
l'attribut audience, présent dans
presque tous les éléments. Il permet donc de spécifier le
niveau de diffusibilité à tous les niveaux d'un document
XML. On peut supposer que ses valeurs seront définies par
une listes d'autorité suivant le contexte d'application du
schéma. Grâce à cet attribut, même une partie séquence de
mots peut se voir appliquer une restriction de
diffusion
l'élément rights du bloc info. Il est
aussi possible d'attribuer à un document ou une partie de
documents des droits particuliers qui peuvent conditionner
sa diffusion.
Le schéma permet plusieurs niveaux de granularité dans la structuration de l'information. Sachant que plus le niveau de structuration et donc la précision sémantique sera fin, plus les possibilités d'exploitation seront grandes. Néanmoins, structurer précisément demande du temps et peut s'avérer rébarbatif à faire pour la personne en charge de ce travail. Il s'agit donc de déterminer le gain par rapport au coût en temps et d'adopter un compromis.
[dc00] .
[dc1] La Rochefoucauld François (de) . - Maximes.
enregistrement découpé en blocs Dublin Core avec un premier niveau sémantique
[dc2] La Rochefoucauld, François, duc de. - Maximes.
structuration du nom de l'auteur ; il est maintenant possible de faire varier l'affichage du nom de l'auteur Nom, prénom ou Prénom Nom.
[dc3] de La Rochefoucauld, François. - Maximes.
L'échelle de niveau de granularité peut aussi être gravie par étape en fonction des moyens. Il est possible d'envisager que dans un premier temps, on se contente du premier niveau de structuration et qu'ensuite on y revienne pour appliquer une deuxième couche de structuration sémantique.
Le schéma SDAPA est aussi un schéma documentaire. A ce titre, la structuration sémantique est poussée très loin et permet plusieurs niveaux de structuration. Ainsi, dans la perspective d'une exploitation documentaire, il n'est pas suffisant d'utiliser l'élément creator pour spécifier qu'il est question d'un auteur. S'agit-il d'une personne morale ou physique ? Ou alors d'une manifestation ? Si cette précision est connue et notifiée, des outils pourront l'exploiter et offrir des index de noms de personnes ou des classifications des ressources.
La notion de structuration sémantique en tant qu'élément filial découle de la structure hiérarchique des documents XML mais on peut encore aller plus loin et le schéma SDAPA en fait le pari. En effet, le schéma est appelé à s'appliquer à des documents en grande partie rédactionnels. Or dans ce cas-là, la plupart de l'information est contenue dans des éléments de niveau bloc, du type paragraphe et ne peut donc pas être exploité sémantiquement à moins de disposer d'éléments d'enrichissement sémantique au même titre qu'il est possible de faire de l'enrichissement typographique.
Le schéma SDAPA est destiné à la production, l'échange et
la gestion de dossiers électroniques. Dans un tel contexte
d'utilisation, le principe de relations et de liens entre
documents ou parties de documents est essentiel. Mais prévoir
les éléments nécessaires pour créer des liens ne suffit pas si
on ne dispose pas d'informations sur la nature de ces liens. Le
lien hypertexte simple du HTML a prouvé ces limites. Ne
serait-il pas plus intéressant de savoir que deux documents sont
liés par une relation d'inclusion, de hiérarchie, de "voir
aussi" ou de "a le même auteur"... Voilà pourquoi dans le
schéma, il est obligatoire de qualifier une relation faite par
l'intermédiaire des éléments relation ou source.
Suivant le même discours, il serait recommandé d'adopter
la même ligne de conduite pour les liens faits par link et donc de donner une valeur
à l'attribut role. Cette contrainte ne fait
pas partie du schéma par analogie avec le lien hypertexte HTML.
Peut-être faudrait-il l'ajouter?
Une des difficultés à travailler avec les schémas est qu'ils ne sont pas toujours bien supportés par les outils XML. Néanmoins, certains permettent de travailler avec cette technologie de manière correcte. Cependant tous les aspects des schémas ne sont pas forcément pris en compte ; notamment la possibilité de gérer des listes de valeurs fermées (listes contraintes à certaines valeurs) ou ouvertes (proposition de valeurs). De plus, les outils de validation intégrés dans ces logiciels ne sont pas nécessairement capables de détecter toutes les erreurs. Aussi est-il recommandé de faire valider un schéma et les instances qui s'y réfèrent par plusieurs outils.
Dans le cadre de ce projet, les logiciels utilisés pour travailler avec le schéma ont été :
XMLSpy<21> d'Altova<22> pour l'édition du schéma, la visualisation du code des instances et leur validation
XMLmind XML Editor<23> pour l'édition d'instances dans une interface graphique ; validation du schéma et des instances. Mais à priori ce logiciel ne gère pas les listes ouvertes.
En plus de ces deux outils, d'autres ont été utilisés pour valider le schéma et les instances :
Internet Explorer Tools<24> pour la validation XML
Topologi XML Validator<25> : outil gratuit pour valider les instances et les schémas XML ou Schematron
XML for ASP.Net XSD Schema Validator<26> : outil en ligne pour valider des instances par rapport à un schéma
DecisionSoft XML Schema Validator<27> : outil en ligne pour valider d'une part un schéma et puis des instances par rapport à un schéma
GotDotNet Applications Server XSD Validator<28> : outil en ligne pour valider des instances par rapport à un schéma
XIVU<29> (XML Instance Validation Utility) : application qui permet de valider des instances par rapport à un schéma pouvant comporter plusieurs namespaces.
Morphon<30> : éditeur XML qui admet les schémas. Pour pouvoir éditer des documents suivant le schéma SDAPA,, il suffit d'écrire une feuille de style pour visualiser les éléments à insérer.
Une solution pour travailler avec la grammaire définie par le schéma peut consister en la traduire en DTD. Certains outils sont capables de faire automatiquement cette traduction.
<1> http://www.dublincore.org/ (Dublin Core)
<2> http://www.docbook.org/index.html (Docbook)
<3> http://www.w3.org/XML/ (norme XML)
<4> http://www.docbook.org/index.html (Docbook)
<5> http://www.w3.org/ (W3C)
<6> http://www.w3.org/XML/Schema (XML Schema)
<7> http://www.opengis.org/docs/02-023r4.pdf (GML)
<8> http://www.opengis.org/docs/02-023r4.pdf (GML)
<9> http://www.openarchives.org/OAI/openarchivesprotocol.html (protocole OAI)
<10> http://www.docbook.org/index.html (Docbook)
<11> http://www.dublincore.org/ (Dublin Core)
<12> http://www.w3.org/MarkUp/ (HTML)
<13> http://www.dublincore.org/documents/dces/ (15 éléments de base du Dublin Core)
<14> http://www.docbook.org/index.html (Docbook)
<15> http://www.w3.org/MarkUp/ (HTML)
<16> http://www.docbook.org/index.html (Docbook)
<17> http://www.opengis.org/docs/02-023r4.pdf (GML)
<18> http://www.docbook.org/index.html (Docbook)
<19> http://www.dublincore.org/ (Dublin Core)
<20> http://www.openarchives.org/OAI/openarchivesprotocol.html (OAI for Metadata Harvesting)
<21> http://www.altova.com/download_spy_enterprise.html (XMLSpy)
<22> http://www.altova.com/ (Altova)
<23> http://www.xmlmind.com/xmleditor/ (XMLmind XML Editor)
<24> http://www.microsoft.com/downloads/details.aspx?FamilyId=D23C1D2C-1571-4D61-BDA8-ADF9F6849DF9&displaylang=en (Internet Explorer Tools)
<25> http://www.topologi.com/products/validator/index.html (Topologi XML Validator)
<26> http://www.xmlforasp.net/SchemaValidator.aspx (XSD Schema Validator)
<27> http://tools.decisionsoft.com/schemaValidate.html (XML Schema Validator)
<28> http://apps.gotdotnet.com/xmltools/xsdValidator/ (XSD Validator)
<29> http://www.dev4net.com/xivu/ (XIVU)
<30> http://www.morphon.com/xmleditor/index.shtml (Morphon)