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

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

  1. Сделайте "XML diff" двух схем, чтобы идентифицировать добавленные/удаленные/измененные узлы.

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

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

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


person Corwin Joy    schedule 05.08.2009    source источник
comment
Вы искали инструмент XML diff и patch?   -  person John Saunders    schedule 05.08.2009
comment
Да, я читал о нескольких инструментах для сравнения и исправления XML, но ни один из них не делает того, что я описал выше.   -  person Corwin Joy    schedule 05.08.2009


Ответы (3)


"Выполните "разницу XML" двух схем, чтобы идентифицировать добавленные/удаленные/измененные узлы."

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

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

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

"Позвольте нам указать функции преобразования..."

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

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

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

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

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

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

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

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

person S.Lott    schedule 05.08.2009
comment
Просто в стороне: XSD - это текст, но есть некоторые несущественные различия, которые улавливает текстовый diff (например, пробелы, выбор / весь порядок). Лучше сказать, что XSD - это XML, поэтому используйте XML diff. Однако на практике это, вероятно, не проблема, потому что это разные версии одной и той же схемы (и, надеюсь, единственные изменения были значительными). - person 13ren; 05.08.2009
comment
С. Лотт приводит здесь несколько замечательных замечаний, но автоматизированный инструмент может помочь. Мой опыт подобных преобразований связан с изменениями схемы базы данных. Я согласен, что к изменениям нужно относиться серьезно. В мире баз данных это обычно сводится к следующему: 1. Добавление/удаление/изменение столбцов или таблиц. 2. Время от времени написание процедуры SQL для сопоставления старых данных с новыми данными. Шаг 1 можно автоматизировать с помощью diff базы данных — инструменты могут это сделать. Шаг 2 требует программирования. Я ищу инструмент XML, который поможет с шагом 1, который также может выполнять более сложные преобразования (например, XSLT) по мере необходимости. - person Corwin Joy; 05.08.2009
comment
@Corwin Joy: не тратьте время на автоматизацию добавления/изменения/удаления столбцов. На практике это будет происходить не так часто. Изменения схемы — это серьезное дело, и для понимания значения этих изменений требуются серьезные ручные процессы. - person S.Lott; 05.08.2009

В итоге я написал инструмент для этого и выпустил результат в виде проекта 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 в папке с документацией.

person Corwin Joy    schedule 31.05.2010

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

person Jacob    schedule 05.08.2009