Пытаюсь прикрутить простенькое версионирование, чтобы не тащить целую подсистему. Сохраняю объект через ЗаписатьXML, потом через ПрочитатьXML сравниваю. Все чудно работает, несколько строк кода, можно открыть старую версию, можно сравнить с новой и т.п. НО.
Если меняем структуру метаданных, естественно, через ПрочитатьXML объект не открывается.
Как преобразовать XML под новый вариант метаданных, используя значения старой версии?

не делай штатную сериализацию.
Нарисуй свой велосипед

взять кусок из бсп

Можно конечно написать преобразование самому - типа читаем пустой объект, обходим узлы сохраненного ХМЛ для чтения значений и заполняем "пустой" хмл. Но не комильфо, думаю есть более простые способы.

(1) да ладно...

Ну так что, красивых вариантов нет?

(5) Ну, я красивый... Но для тебя я не вариант...

(5) прикрутить https://ru.wikipedia.org/wiki/XSLT ?

(3) А ты сохраняешь версию объекта в XML с указанием пространства имен или без?

(0) Можно сохранять старую версию xsd и по ней десериализовыть.

(9) Точняк, уже начитался, осталось понять, как выгрузить XSD схему отдельного объекта метаданных? Есть метод такой?

(10) Ну можно просто скопировать то что нужно. Либо удалить ненужное

(11) Не... Я ведь с данными должен схему выгрузить - а схема должна быть актуальна на момент выгрузки. Если метаданные изменятся - то новая схема уже не подойдет.

Те же проблемы и в стандартном в типовых конфигурациях версионировании: что делать с версиями, когда обновление изменяет метаданные?

Если особо не задумываться, то: загрузить версии из хранилища; обновить конфигурацию; выгрузить версии в хранилище. На первый и не только взгляд - абсурдное решение. Хотя с другой стороны... а что делать-то? Обновление не только метаданные изменяет, оно новые реквизиты - заполняет, существующие - может изменить значения.

(12) Схему выгрузил. Но она огромная. А из всей этой схемы тебе нужно несколько документов.

Можно держать 1 схему и её изменения.

Схемы или правила конвертации - решение? Нет. Допустим, со временем произошло три обновления с изменением метаданных. И? И у вас в хранилище полно версий трех различных схем.

(15) При сохранении указывай нужную версию, а после изменения сохраняй схему и назначей ей версию. К сожалению это будет в ручном режиме

Не выход. Даже если будешь знать информацию о версии конфигурации. Через пару/тройку обновлений с изменениями метаданных, эта информация будет уже ни о чём.

Не станешь же ты версию, времен Адама и Евы, последовательно прогонят через все изменения метаданных (всё это как-то и где-то хранить).

В типовых конфигурация последовательно процедуры обновления используются, когда "перескакиваешь" через версии - их тоже хранить будешь? Имхо, через чур замороченное решение получается :(

(17) Если ты будешь выгружать и сохранять в XSD каждую версию
то для десериализации используешь свою версию XSD.

Сохраняй версию как структуру с полями, соответствующими реквизитам объекта, таб.части сохраняй как реквизиты типа массив структур.
Восстановление объекта из такой структуры проводи через создание объекта и заполнение значений свойств, таб. части восстанавливай через создание строк и заполнение значений свойств.

Кода получается мало и работает быстро (сопоставимо с XML сериализацией).
Функция копирования объекта в структуру занимает 33 строки, включая пустые строки разделители.
- для объекта из метаданных получаем стандартные реквизитов, реквизиты как поля структуры-копии;
- заполняем структуру-копию из объекта;
- для табчасти из списка табчастей из метаданных получаем стандартные реквизиты и реквизиты как поля структуры-строки, в структуру-копию добавляем поле с названием табчасти и типом Массив;
- для каждой строки текущей табчасти добавляем в массив структуру-строку с заполнением этой структуры из строки.
Функция восстановления объекта из структуры занимает те же 33 строки.
Версию храни в хранилище значения со сжатием данных.