Stratégie de compatibilité de schéma XML

Question

Je travaille avec une application qui utilise un grand nombre d'interfaces xml pour l'intégration et l'importation/exportation de données. Nous utilisons JAXB pour mapper de ces interfaces à notre modèle d'objet de domaine. Un défi auquel nous sommes fréquemment confrontés est de savoir comment faire face à la nécessité de passer à ces interfaces au cours d'un projet face à de nouvelles exigences.

Dans le monde idéal, toutes les exigences sont connues à l'avance. La spécification XML sera rédigée pour refléter ces exigences et ne sera jamais modifiée. Dans le monde réel cependant, les lacunes qui affectent les interfaces sont découvertes tout au long du cycle de vie du projet. Certains de ces changements sont bénins dans leur impact (par exemple en introduisant un nouveau champ non requis). Pour d'autres types de changements, il existe une option permettant de les implémenter de manière «non propre», qui préserve la rétrocompatibilité ou une méthode «propre» qui ne le fait pas. Par exemple, disons qu'il existe une nouvelle exigence pour ajouter 'Field2' partout où 'Field1' apparaît dans le schéma. Depuis « Champ1 » et « champ2 » sont fonctionnellement/regroupées de manière logique, l'approche la plus naturelle (nous l'appellerons « approche 1 ») est de remplacer les usages de:

<Field1></Field1> 

avec

<GroupingName> 
    <Field1></Field1> 
    <Field2></Field2> 
</GropuingName> 

La bonne chose à propos de l'approche 1 est qu'il est facile à mettre en œuvre et à maintenir. Le gros inconvénient est qu'il a cassé l'interface. Tous les XPath existants à Field1 doivent être modifiés. L'alternative ("Approche 2") consiste à introduire Champ2 en même temps que Champ1 sans l'étiquette de regroupement.

<Field1></Field1> 
<Field2></Field2> 

Approche 2 préserve en arrière, mais viole la compatibilité « SEC » et ne garantit pas que Champ2 apparaît partout le Champ1 fait.

Ma question est, quelles sont les normes/meilleures pratiques de l'industrie pour le traitement des changements xml face aux nouvelles exigences Est-il:

1. force apporach 1 sur le client (nouveaux besoins = changements d'interface
2. Tenez votre nez et prenez l'approche 2.
3. Branchez la base du code. Implémentez l'approche 2 dans la branche et adoptez l'approche 1 dans le tronc principal. (Moins réalisable au début du projet).
4. Autre?

Answer 1

Modifier le XSD pour définir un groupe nommé; pas un type complexe:

et remplacer chaque déclaration d'élément de « Champ1 » avec cela assure que « champ2 » doit se produire après « Champ1 » partout « Champ1 » se produit. Défini si l'occurrence est facultative.