2004 01 07 2004-06-24 Bougoüin Christine AJLSM 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. 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 et Docbook. 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. 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 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. Pour répondre aux nouveaux développements (espaces de noms) de XML qu'il a édicté, le W3C se devait de proposer un langage de modélisation en XML ; il s'agit de XML Schema. 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 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).*** 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. 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 choisi comme schéma de base, Dublin Core pour les métadonnées, HTML 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, 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. 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. 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 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. 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, du principe des index extrait de Docbook, éventuellement du recours à GML pour traiter les coordonnées géodésiques. 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 proper sous title name, value sous property tr sous tbody, thead ou tfoot orgname sous organization term sous concept question sous faq role pour relation, source, link : une relation entre deux ressources doit être qualifiée. scheme pour width, length, height 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 : xs:ID pour id, pour la définition d'identifiants uniques globaux pour tout un document. Cela offre un moyen pour identifier de manière unique l'élément qui les porte et permet ainsi de définir des ancres. xs:anyURI pour uri, défini des URI selon les normes RFC 2396 et 2732.

Le schéma SDAPA est basé sur deux modèles standards Docbook et Dublin Core. 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.

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 ? Même si l'usage d'une liste de valeurs aurait été pertinent pour quelques éléments, après réflexion il a été décidé que cela ne valait pas le niveau de restriction impliqué. Il est toujours possible d'ajouter des couches supplémentaires de contraintes par d'autres moyens notamment les outils d'édition et de validation.

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 coverage : xs:string ; spatial, temporal role de description : xs:Name ; history, contents, index, note, howto, inscription, abstract role de event : xs:string ; Exposition scheme de identifier : xs:string ; URI, ISBN, ISSN, DOI, number role de format : xs:Name ; physical, digital scheme de height, width : xs:string ; px, mm, cm, in, ft, m, km role de contact, email, fax, phone : xs:string ; home, work, pref role de term : xs:string ; normal, preferred scheme de length : xs:string ; o, Ko, Mo, Go scheme de markup : xs:string ; xml, html scheme de type : xs:string ; DCMIType 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'attribut @audience peut permettre de préciser qu'une partie de document n'est pas autoriser à être diffuser publiquement pour diverses raisons (le public n'est pas qualifié pour comprendre!). 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. La Rochefoucauld, François (de). Maximes. La Rochefoucauld François (de) enregistrement découpé en blocs Dublin Core avec un premier niveau sémantique François duc de La Rochefoucauld 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. François de La Rochefoucauld 1613 Paris 1680 Paris 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 d'Altova pour l'édition du schéma, la visualisation du code des instances et leur validation XMLmind XML Editor 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 pour la validation XML Topologi XML Validator : outil gratuit pour valider les instances et les schémas XML ou Schematron XML for ASP.Net XSD Schema Validator : outil en ligne pour valider des instances par rapport à un schéma DecisionSoft XML Schema Validator : 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 : outil en ligne pour valider des instances par rapport à un schéma XIVU (XML Instance Validation Utility) : application qui permet de valider des instances par rapport à un schéma pouvant comporter plusieurs namespaces. Morphon : é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.