Je dois souvent concevoir des schémas XML pour différentes routines d’importation de bases XML. Il est clair que les schémas XML évolueront avec le temps ou qu’ils pourront contenir des bogues à corriger, il est donc important de capturer la version du schéma et de disposer d’un mécanisme permettant de lier une version spécifique.
Actuellement, j’ai deux scénarios:
Le bogue se trouve dans le schéma et toutes les instances de schéma doivent être conformes à la version corrigée.
Le schéma mis à jour et devrait être considéré comme préférable, mais un ancien doit également être pris en charge.
Enfin, j’ai trouvé des informations sur la version dans l’espace de noms du schéma:
targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd"
Lorsque je corrige un bogue, je le répare dans le même espace de noms mais si je suis sur le sharepoint mettre à jour un schéma, je dois créer un nouvel espace de noms mais avec le mois de mise à niveau ajouté:
targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd"
Et si j’ai plus d’une mise à jour en un mois, il suffit d’append une journée:
targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd"
Connaissez-vous une meilleure approche?
C’est un sujet tellement difficile que ce n’est même pas drôle et que j’ai passé des années à fournir des services de conseil.
Il existe de nombreuses meilleures pratiques , mais la plupart ne fonctionnent pas dans toutes les situations. Par exemple, beaucoup préconisent l’utilisation de “xsd: any” pour autoriser les extensions, ce qui est une recette pour un désastre si les développeurs sont responsables de la maintenance du schéma, ce qui en fait un dump.
Voici quelques conseils pour vous aider à démarrer:
Bonne chance!
http://www.xml.com/pub/a/2004/07/21/design.html fournit de bonnes directives et XML Schema 1.1 permet le «versionning» via l’inclusion conditionnelle ( http://www.w3.org/TR/ xmlschema11-1 / # cip ).