Evolution d'un schéma XML

Cette page est plus une réflexion personnelle qu'une politique à respecter. Elle apporte des informations à mon sens importantes sur les raisons d'une évolution des DTD guidée par les besoins communs des auteurs, indépendamment de tout outil. Elle est a mettre dans le contexte de l'évolution des schéma XML des Universités Numériques Thématiques. On trouve beaucoup de lecture sur la maintenance technique des schéma et les problèmes de cohérence schémas-données mais peu d'information sur la sélection éléments dans le but d'enrichir une DTD pour mieux répondre au besoins (dans ce document j'utiliserais les termes DTD et schéma XML de manière interchangeable, ce qui n'est pas grave pour une étude non technique).

5 étapes pour faire évoluer la DTD

1 - exprimez vos besoins (dès le départ pour montrer l'exemple), demandez aux autres de proposer leurs besoins

2 - identifiez précisément de qui a besoin d'une fonctionnalité précise (quel établissement, dans quel contexte), sélectionnez des exemple, quantifiez subjectivement de l'importance et du nombre d'usages prévus, "existe t'il une alternative simple et propre pour répondre à ce besoin avec la DTD actuel ?". Les besoins peuvent être soit basés sur un fait, un exemple de réalisation, du type "3 universités utilisent actuellement des exercices de type texte à trous sans pouvoir les représenter", soit un souhait "presque personne n'est en mesure de créer facilement tel nouveau type d'exercice, pourtant on est en mesure de l'expliquer simplement et si on en disposait tout le monde l'utiliserait" (dans ce 2eme cas, cela fait appel à une estimation et il faut donc être plus prudent, mais d'un autre coté le fait qu'un élément ne soit pas dans la DTD n'incite pas à penser à l'utiliser). Éliminez les besoins vraiment marginaux et exceptionnels, qui ne rentrent pas dans le cadre de la DTD : elle décrit des usages relativement courants.

3 - définition fonctionnel d'une fonctionnalité ou d'un besoin) : que cherche t'on à faire exactement ? Clarification de l'étape 1 et 2 qui peut être relativement vague.

4 - choix de la structure logique et de la nomenclature des éléments à ajouter :

• Structure logique :
  • si un autre groupe de travail a déjà étudié les mêmes besoins il est vivement recommandé de partir de la même structure logique (exemple : la structure des exercices UNISCIEL pour intégration dans UVED)
  • si lors de la collecte des retours d'usage et d'identification, on a obtenu des exemples de réalisations, on peut aussi s'en inspirer pour déduire une structure logique (par exemple si 3 universités ont produit des modules avec des textes a trous, peut être que l'on peu s'intéresser à la manière dont ils sont édités et stockés)
  • le but est de faire une structure logique simple, tout en pensant aussi aux prochaines évolutions envisageables ("actuellement nous avons le besoin X, si nous avons le besoin X++ à l'avenir, le choix de structure logique étudié pour répondre au besoin X facilitera t'il ou freinera t'il la réponse au besoin X++ ?")
• La nomenclature (nom des balises) :
  • dépend plus du reste de la DTD concernée par l'ajout, pour s'assurer de choisir des noms cohérents avec les mots existants.

5 - modification des fichiers de la DTD : intégration des éléments formalisés par l'étape 3

6 - à terme, on souhaite progressivement l'évolution des outils, les développeurs ont déjà le travail de "représentation de l'information" pour les guider dans l'implémentation

les étapes 1, 2 et 3 sont réalisées par des personnes avec un profil pédagogue, l'étape 4 nécessite la collaboration des personnes des deux profils (pédagogue et technique), l'étape 5 est réalisée par une personne avec un profil technique.

Les raisons de l'évolution

• ce sont les besoins pédagogiques qui doivent être formalisés dans une DTD, pour permettre et suggérer l'évolution des outils dans le même sens
• non pas l'approche inverse dans laquelle les capacités des outils (ou d'un outil) freinent l'évolution de la DTD, en d'autres mots les limites techniques dictent ce que le pédagogue a le droit d'exprimer.
• la démarche "chercher à répondre au besoin" permet à la fois une DTD légère et une DTD complète : rajouter des éléments pour lequel personne n'entrevoit un usage alourdit la DTD, mais refuser de répondre a un besoin réel la rend incomplète (et non légère), les deux situations sont gênantes. (ref #Conceptual XML Schema Evolution1)
• le risque d'avoir une DTD incomplète est d'encourager les auteurs à mettre des éléments de type "contenu" en tant que ressource externe ou de forcer les auteurs à utiliser des éléments de contenus qui ne peuvent pas être représentés dans la DTD. Cela tends à exclure ces besoins du respect de l'interopérabilité : une DTD incomplète, c'est une interopérabilité incomplète.

Références

Conceptual XML Schema Evolution1

Conceptual XML Schema Evolution - the CoDEX approach for Design and Redesign
Meike Klettke - University of Greifswald, Germany
 http://dbs.cs.uni-duesseldorf.de/BTW2007/Klettke.pdf

"Software aging will occur in all successful product." (David Parnas, [22]).
Parnas gives two (very dierent) reasons for software aging. The first is caused
by the failure of the product's owners to modify it to meet changing needs; the
second is the result of the changes that are made [22].
We have to consider that all data which are represented in XML documents
also ages and have to be updated from time to time.