Стратегия совместимости схемы XML

Question

Я работаю с приложением, которое использует большой набор xml-интерфейсов для интеграции и импорта/экспорта данных. Мы используем JAXB для сопоставления этих интерфейсов с нашей объектной моделью домена. Одна из проблем, с которыми мы часто сталкиваемся, заключается в том, как решить проблему изменения этих интерфейсов в ходе проекта перед лицом новых требований.

В идеальном мире все требования известны спереди. Спецификация xml будет разработана для отражения этих требований, а затем никогда не будет изменена. Однако в реальном мире пробелы, которые влияют на интерфейсы, обнаруживаются на протяжении всего жизненного цикла проекта. Некоторые из этих изменений являются мягкими в их воздействии (например, введение нового необязательного поля). Однако для других типов изменений есть возможность реализовать их «нечистым» способом, который сохраняет обратную совместимость или метод «чистого», который этого не делает.

Например, необходимо добавить новое поле «Field2», в котором поле «Field1» появляется в схеме. Так как 'Field1' и '' Field2 функционально/логически сгруппированы, наиболее естественный подход (мы будем называть его "подход 1"), чтобы заменить обычаи:

<Field1></Field1> 

с

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

Самое приятное в подходе 1 заключается в том, что его легко внедрять и поддерживать. Большим недостатком является то, что он сломал интерфейс. Все существующие XPath's для Field1 должны быть изменены. Альтернативой («Подход 2») является введение Field2 вместе с Field1 без метки группировки.

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

подход 2 сохраняет обратную совместимость, но нарушает «DRY» и не гарантирует, что Field2 появляется везде Field1 делает.

Мой вопрос, какова отраслевые стандарты/передовая практика, для обработки изменений XML перед лицом новых требований ли:

1. Force apporach 1 на клиенте (новые требования = изменения в интерфейс)
2. Держите нос и приближайтесь 2.
3. Вставьте кодовую базу. Внедрите подход 2 в ветку и возьмите подход 1 в основной багажнике. (Менее работоспособный в начале проекта).
4. Другое?

Answer 1

Измените XSD, чтобы определить именованную группу; не тип комплекса:

и заменить каждый элемент декларации "Field1" с это гарантирует, что "Field2" должно произойти после "Field1" везде "Field1" происходит. Установите, если событие не является обязательным.