Советы по разработке формата файла сериализации, который позволит легко объединить

Question

Допустим, я создаю инструмент моделирования UML. Существует некоторая иерархическая организация данных, и элементы модели должны иметь возможность ссылаться на других. Мне нужен какой-то способ сохранить файлы моделей на диск. Если над файлами могут одновременно работать несколько человек, наступит время объединить эти файлы моделей. Также было бы неплохо сравнить две ревизии в системе контроля версий и посмотреть, что изменилось. Похоже, что это будет общая проблема во многих доменах

Чтобы это работало с использованием существующих инструментов различий и слияния, формат файла должен быть текстовым, разделенным на несколько строк.

Какие существуют форматы сериализации, которые хорошо (или плохо) справляются с такими проблемами? Или, если вы разрабатываете нестандартный формат файла, какие советы / рекомендации / подводные камни?

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

Answer 1

Я давно решил эту проблему для октавы / матлаба, теперь мне нужно что-то для C #.Задача состояла в том, чтобы объединить две октавные структуры в одну.Я не нашел ни инструмента слияния, ни подходящего сериализатора, поэтому мне пришлось кое о чем подумать.

Самым важным концептуальным решением было разделить структурное дерево на строки с полным путем и содержанием отпуска.

Основной идеей было

1. Сериализация структуры в строки, где каждая строка представляет базовую переменную (Matrix, string, float, ...)
2. Массив или матрица структуры будет иметь индекс в пути.
3. объединить два результирующих текстовых файла, отсортировать строки
4. обнаружить коллизии и обработать коллизии (очень легко, потому что одни и те же свойства будут расположены непосредственно под друг другом после сортировки строк)
5. выполнить десериализацию

Пример:

>> s1

s1 =

скалярная структура, содержащая поля:

b =

  2x2 struct array containing the fields:

    bruch

t = Textstring
f =  3.1416
s =

  scalar structure containing the fields:

    a =  3
    b =  4

будет сериализовано до

root.b(1,1).bruch=txt2base('isfloat|[ [ 0, 4 ] ; [ 1, 0 ] ; ]');
root.b(1,2).bruch=txt2base('isfloat|[ [ 1, 6 ] ; [ 1, 0 ] ; ]');
root.b(2,1).bruch=txt2base('isfloat|[ [ 2, 7 ] ; [ 1, 0 ] ; ]');
root.b(2,2).bruch=txt2base('isfloat|[ [ 7 ] ; [ 1 ] ; ]');
root.f=txt2base('isfloat|[3.1416]');
root.s.a=txt2base('isfloat|[3]');
root.s.b=txt2base('isfloat|[4]');
root.t=txt2base('ischar|Textstring');

Преимущество этого метода в том, что он очень прост в реализации и удобочитаем.Сначала вы должны написать две функции base2txt и txt2base, которые конвертируют базовые типы в строки и обратно.Затем вы просто идете рекурсивно по дереву и пишете для каждого свойства структуры путь к свойству (в данном случае разделенный ".") И содержимое в одну строку.

Большой недостаток в том, что по крайней мере моя реализацияэто очень медленно.

Ответ на второй вопрос: уже есть что-то подобное?Я не знаю ... но я искал некоторое время, поэтому я так не думаю.

Answer 2

Некоторые рекомендации:

Формат должен быть спроектирован таким образом, чтобы при изменении только одной вещи в модели существовало только одно соответствующее изменение в файле. Некоторые контрпримеры:

• Бесполезно, если в формате файла используются произвольные ссылочные идентификаторы, которые меняются при каждом редактировании и сохранении модели.
• Бесполезно, если элементы массива хранятся с явно указанными их индексами, поскольку вставка элементов в середину массива приведет к смещению всех следующих индексов. Это приведет к тому, что эти элементы будут отображаться в «diff» без необходимости.

Относительно ссылок: если идентификаторы создаются последовательно, то два человека, редактирующие одну и ту же ревизию модели, могут в итоге создать новые элементы с одинаковым идентификатором. Это станет проблемой при слиянии.