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

Question

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

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

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

<Field1></Field1>

с

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

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

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

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

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

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

Answer 1

Изменить XSD для определения именованной группы;не сложный тип:

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