Миграция XML-схемы

Question

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

1. Выполните «XML diff» из двух схем для идентификации добавленных / удаленных / измененных узлов.

2. Позвольте нам указать функции преобразования. Так, например, мы могли бы добавить в нашу схему новый элемент, который является функцией старых элементов. (Например, новый элемент C, где C = A + B, A + B - старые элементы).

Так что я думаю, что я ищу некий инструмент различий и исправлений XML, который также может применять функции преобразования. Один инструмент, на который я обращаю внимание, это MapForce Альтовы . Я уверен, что другие здесь имели дело с миграцией формата данных XML. Как ты с этим справился?

Edit: Одно уточнение. «Разница», которую я планирую сделать, находится в файлах схемы или .xsd. Фактические изменения будут внесены в конкретные наборы данных, которые следуют данной схеме. Эти наборы данных будут .xml файлами. Таким образом, это «разница» схемы, помогающая выяснить, какие изменения необходимо внести в наборы данных, чтобы перенести их из одной схемы в другую.

Answer 1

"Выполните" XML diff "из двух схем для идентификации добавленных / удаленных / измененных узлов."

XSD - это текст, так что это тривиально.

Однако, если вы внесете кардинальные структурные изменения в XSD, автоматическое различие будет в значительной степени бесполезным.

Если вы вносите небольшие косметические изменения в XSD, это может быть полезно.

«Разрешить указывать функции преобразования ...»

Разве это не было бы хорошо. К сожалению, вероятность того, что произойдет какое-то тривиальное изменение («новый элемент C, где C = A + B, A + B - старые элементы»), почти равна нулю. Зачем делать такие тривиальные изменения?

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

Нет, вероятность того, что автоматическая миграция схемы будет почти равна нулю.

Вместо этого дизайн для переносимости.

1. Убедитесь, что номер версии виден в ваших путях XSD. В идеале в самом имени XSD.

2. Каждое изменение XSD является серьезной проблемой управления (SGI ™). Все участвуют. И вы пишете сценарии миграции прямо здесь и сейчас. Не после. Не с инструментами. Но как часть изменения XSD.

   Схема не меняется спонтанно. Кто-то меняет их по причине. Чтобы кто-то мог указать изменения, чтобы кто-то другой мог написать (или обновить) скрипт миграции.

Это слишком, слишком серьезно, чтобы доверять "автоматизированным" инструментам. Для этого нужны настоящие мозги реальных людей, которые действительно сосредоточены на этом, как если бы их работа зависела от этого.

Answer 2

В итоге я написал инструмент для этого и выпустил результат в виде проекта SourceForge.

Что: Этот инструмент помогает создавать сценарии для переноса данных XML из одной версии схемы XML в более позднюю версию той же схемы. Инструмент создает эти сценарии, различая файлы XSD и испуская XSLT 2.0 для автоматической миграции данных XML. Это хорошо работает для простых изменений данных и может использоваться как «стартовый» код для более сложных изменений данных.

Где: https://sourceforge.net/projects/xsdevolver/

Справка: Компания, в которой я работаю, продает термоусадочное приложение, в котором мы сохраняем книгу в формате XML в соответствии с указанной схемой XSD. Со временем мы ожидаем, что формат этой схемы изменится. Нам нужен был способ помочь нам различать версии схемы по мере их развития и генерировать исходный XSLT для переноса данных из более старых версий схемы в более новые версии схемы.

Использование:

XMLSchemaEvolver SchemaVersion1.xsd SchemaVersion2.xsd

Выход:

1. Схема, показывающая, какие элементы были изменены

2. XSLT для перевода данных XML из SchemaVersion1 в SchemaVersion2

Как это работает?

Основная идея такова:

1) Выполните сравнение двух файлов схемы XML (xsd).

2) Каждое изменение классифицируется как операция INSERT, DELETE, MOVE или RENAME.

3) Для каждой из этих операций выведите простой XSLT для выполнения требуемого изменения данных.

4) Эти операции изменения данных смоделированы после набора стандартных операций XSLT, предложенных Джеспером Тверсковым текст ссылки . Полный список преобразований, генерируемых нашим кодом, можно найти в файле документации XSLT Transformations.txt.

Answer 3

Как говорит @ S.Lott, возможность автоматизировать преобразования маловероятна. Тем не менее, XSLT является фантастическим инструментом для формального определения того, как преобразовать XML из одного формата в другой. Он не может быть сгенерирован автоматически (насколько я знаю), но это стоит того, чтобы так поступить.