Сравнение форматов

EOC или обычный архив: в чём разница для проекта

Архив удобно использовать для упаковки файлов. EOC добавляет к переносимому набору явные роли компонентов, ревизию и проверяемые связи. Разница проявляется не в расширении файла, а в том, какие вопросы можно задать перед восстановлением.

Обновлено: 8 минутПросмотры загружаются
Сравнение архива и EOC: файл слева, состав и проверка справа

Обычный архив отвечает на вопрос «как передать набор байтов одним файлом». Проверяемый объект отвечает на более широкий вопрос: «какое состояние проекта передано, из каких компонентов оно состоит и что именно было проверено».

Что делает обычный архив

ZIP, TAR, 7z и другие архивные форматы решают задачу упаковки. Они объединяют файлы, могут сжимать данные и помогают передать каталог через один канал. При распаковке получатель получает содержимое, которое было помещено внутрь архива. Для резервной копии или простой пересылки этого часто достаточно.

При этом архивный формат не обязан знать, какой файл является опубликованным результатом, какой нужен для редактирования, а какой служит зависимостью. Эти сведения можно хранить в именах, структуре каталогов или отдельном README. Но тогда их смысл зависит от договорённости между участниками. Само наличие файла в архиве ещё не сообщает, к какой версии проекта он относится.

Архив также не гарантирует корректность внешнего контекста. Можно добавить контрольную сумму рядом с архивом, подписать пакет или вести журнал передачи. Это полезные меры, однако они появляются как отдельные процедуры. Если получатель не знает, какую сумму проверять и какой состав считать обязательным, технически успешная распаковка не превращается в доказательство согласованности проекта.

Что добавляет модель EOC

EOC, или Evidence Object Container, описывает цифровой объект через состав и отношения. В публичной модели Recoverable фиксированное представление результата, редактируемое состояние и данные ревизии имеют разные роли. Они могут храниться внутри переносимого контейнера, но важнее то, что их связь выражена явно и может быть проверена.

Получатель может сформулировать проверяемые условия: присутствует ли обязательный компонент, совпадает ли его SHA-256, относится ли он к выбранной ревизии и допустимо ли продолжать восстановление. Такой контракт не делает содержимое автоматически правильным. Он фиксирует границу утверждения: набор соответствует сохранённому описанию либо обнаружено несоответствие.

Практическая граница: EOC не отменяет архивирование и резервное копирование. Он задаёт проверяемый контекст для набора. Архив может быть способом физической упаковки, а EOC — способом описать, что именно упаковано и как это проверять.

Сравнение по рабочим вопросам

При выборе подхода полезно сравнивать не бренды и не расширения, а вопросы эксплуатации. Для обычного архива основной вопрос — извлекаются ли файлы и совпадает ли контрольная сумма архива, если она была сохранена. Для EOC добавляются вопросы роли, ревизии, обязательного состава и решения перед restore.

  • Состав: архив хранит включённые файлы, EOC может связывать их с ролями и descriptor-компонентами.
  • Целостность: оба подхода могут использовать SHA-256, но EOC включает контрольные значения в модель проверяемой ревизии.
  • Версия: архиву требуется внешнее правило именования или manifest, EOC делает ревизию частью объекта.
  • Восстановление: распаковка архива извлекает содержимое, а restore проверяемого объекта может быть разрешён только после проверки.
  • Границы доверия: ни архив, ни EOC не исправляют ошибочные исходные сведения и не заменяют контроль доступа.

Пример для инженерного проекта

Предположим, передаётся комплект, в котором есть PDF результата, исходная модель, таблица параметров и библиотека. Архив сохранит все четыре файла, если их положили внутрь. Но без явного описания получатель может не понять, какая модель соответствует PDF, обязательна ли таблица и можно ли заменить библиотеку похожей копией.

В EOC эти отношения фиксируются для конкретной ревизии. PDF обозначается как fixed representation, рабочая модель — как editable source, таблица и библиотека — как связанные материалы. Контрольные суммы позволяют обнаружить изменение байтов, а связь ревизии не даёт принять комплект из разных этапов как один. Если обязательный материал отсутствует, корректный результат — понятная блокировка и отчёт, а не автоматическая подстановка случайной копии.

Когда достаточно архива

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

EOC становится полезнее, когда результат нужно связать с редактируемым состоянием, повторно скачать без новой упаковки, показать историю ревизий или восстановить исходники конкретной версии. В таком процессе оператору требуется не только файл, но и воспроизводимое объяснение, почему выбранный набор принят или заблокирован.

Итог

Разница между EOC и обычным архивом — в уровне описания объекта. Архив объединяет данные для передачи. EOC объединяет данные с проверяемой моделью состава, ролей и ревизии. Они могут использоваться вместе: архив отвечает за упаковку, а EOC — за идентичность набора и порядок проверки. Перед внедрением следует определить обязательные компоненты, источник контрольных сумм, политику версий и допустимое действие при ошибке.