OMI-SPEC-320 — Формат на файла

Метаданни на документа

Поле	Стойност
Идентификатор	OMI-SPEC-320
Заглавие	Формат на файла
Версия	0.2.0
Статус	Чернова
Вид документ	Нормативен
Нормативен език	Английски
Редактори	Администратори на OMI
Последно актуализирано	05.09.2026
Идентификатор от предишната версия	OMI-SPEC-011
Заменя	OMI-SPEC-320@0.1.0
Заменено с	Няма
Зависи от	OMI-SPEC-100, OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-160, OMI-SPEC-180
Използва се от	OMI-SPEC-230, OMI-SPEC-330, OMI-SPEC-340, OMI-SPEC-350
Схема	omi-manuscript-0.2.schema.json
Тип медия	application/vnd.openmanuscript+json (предварителен)
Разширение на файла	.omi.json
Профили	Моментална снимка на ядрото; Обмен на история; Кръгъл цикъл без загуба
Статус на изпълнението	OMI Implementation Status Matrix
Система за проследяване на проблеми	Проблеми в репозиторията на Open Manuscript Initiative

1. Резюме

Настоящата спецификация определя преносимото логическо представяне на ръкопис в формат „Open Manuscript Initiative“. Тя описва документ в формат UTF-8 JSON, идентификационна обвивка с версия, задължителни полета в ръкописа, подредени семантични колекции, препратки, данни за разширение, опционален обмен на история, поведение при анализиране и сериализация, валидиране на слоеве, диагностика, запазване на неизвестни полета и записи за миграция.

Форматът отразява състоянието на научния документ, а не оформлението на страницата или състоянието на документа по време на работа на редактора. Дадена реализация може да съхранява един и същ ръкопис в база данни, регистър на събитията, няколко файла или друга вътрешна форма, но експортиран ръкопис в формат „OMI“, съответстващ на настоящата спецификация, притежава същата наблюдаема семантика, описана на адрес JSON.

Настоящата спецификация умишлено не определя физическия архив „.omi“, структурата на ZIP-елементите, контролните суми, компресията или правилата за пътя към пакета. Тези въпроси са предмет на OMI-SPEC-330 — Container Architecture. Контейнерът може да съдържа документ, съответстващ на настоящата спецификация, като една от неговите части.

2. Статус на настоящия документ

Настоящият документ представлява проект на спецификация на стандарта „Open Manuscript Initiative“.

Версия 0.2.0 е първият пълен проект на файлов формат, съдържащ схема на файловата система (JSON), тестови набори за съответствие, изрични правила за обработка и стабилни идентификатори на изискванията. Той замества непълния проект 0.1.0, който съчетаваше аспектите на логическия формат и физическия контейнер, без да дефинира съвместимо поведение при анализиране или валидиране.

Имената на свойствата, профилите, ограниченията на схемата и правилата за миграция все още могат да претърпят промени, водещи до несъвместимост, преди версия 1.0. Декларацията за съответствие ТРЯБВА да посочва точно тази версия на спецификацията или неизменна ревизия от хранилището.

Публикуваната схема има нормативен характер по отношение на структурните ограничения. Изискванията, изложени в текста, регулират семантиката, обработката, сигурността, съхранението и поведението при двупосочен обмен, които схемата „JSON“ не може да изрази. Когато възникне противоречие между схемата и настоящия документ, то се счита за недостатък в спецификацията и имплементациите ТРЯБВА да го докладват; докато не бъде отстранено, се прилага изискването, изложено в текста, което има по-конкретен идентификатор на изискването.

3. Съответствие

3.1 Нормативни термини

Ключовите думи ТРЯБВА, НЕ ТРЯБВА, ЗАДЪЛЖИТЕЛНО, ПРЕПОРЪЧВА СЕ, НЕ ПРЕПОРЪЧВА СЕ, МОЖЕ и НЕЗАДЪЛЖИТЕЛНО трябва да се тълкуват съгласно описаното в BCP 14, когато и само когато са изписани изцяло с главни букви.

Всяко нормативно изискване в този документ има постоянен идентификатор във формата REQ-FMT-NNN. В доклад от изпитване, проблем, изключение или твърдение за имплементиране СЛЕДВА да се посочат съответните идентификатори.

3.2 Класове на съответствие

Настоящата спецификация дефинира пет класа за имплементиране:

• Производител, отговарящ на изискванията: създава или изнася документ в формат „OMI“.
• Съвместим потребител: анализира, импортира, представя, индексира или преобразува документ от типа „OMI“.
• Валидатор за съответствие: анализира документ и предоставя структурирана диагностика.
• Конвертор за съобразяване: преобразува документ от една декларирана версия на формат в друга.
• Процесор, съответстващ на стандарта за беззагубна обработка: чете и записва документ, като запазва всеки поддържан и неподдържан елемент от данните, който не променя умишлено.

Една реализация МОЖЕ да претендира за повече от един клас. Съответстващата реализация ТРЯБВА да отговаря на всички изисквания, приложими към класовете и профилите, за които претендира.

3.3 Профили за съответствие

В декларацията за съответствие ТРЯБВА да бъде посочен поне един от следните профили.

Основна снимка

Профилът „Core Snapshot“ обменя едно текущо състояние на ръкописа. За целта са необходими идентификационният пакет на корена, идентификаторът на ръкописа, езикът, заглавието, йерархията на разделите и времевите отметки. Това не означава, че е налице история на ревизиите.

Обмен на исторически данни

Профилът „History Exchange“ обменя текущото състояние заедно с преносима история на ревизиите, регулирана от OMI-SPEC-160. Той изисква изрична декларация за пълнота на историята, начална ревизия и вътрешно последователни връзки между ревизиите.

Беззагубно пътуване в двете посоки

Профилът „Lossless Round Trip“ се прилага за процесори, които може да не разпознават всички разширения или бъдещи полета. Такива процесори запазват неизменените неизвестни данни и сигнализират за всяка поискана операция, която би ги изтрила или преинтерпретирала.

3.4 Декларация за съответствие

В декларацията за съответствие СЛЕДВА да се посочи:

• име и версия на реализацията;
• OMI-SPEC-320 версия;
• клас или класове за реализация;
• деклариран профил или профили;
• поддържан диапазон от версии на формати;
• поддържани пространства от имена на разширения;
• максимален допустим размер на входните данни, дълбочина на вложеността и размери на колекциите;
• възможности за валидиране и миграция;
• използваният набор от тестови случаи или версията на теста;
• известни ситуации, при които се стига до загуба на данни.

REQ-FMT-001: Производителят ТРЯБВА да генерира обект от най-високо ниво от типа „JSON“, който отговаря на изискванията за идентификация, модел на данните и сериализация, посочени в настоящата спецификация.

REQ-FMT-002: Потребителят ТРЯБВА да определи декларирания формат и версия на „OMI“, преди да интерпретира полетата на ръкописа.

REQ-FMT-003: Валидаторът ТРЯБВА да оцени синтаксиса на JSON, схемата, съответстваща на версията, приложимите семантични ограничения и всеки деклариран профил.

REQ-FMT-004: Програмата за миграция ТРЯБВА да запази оригиналния входен файл и да създаде изричен запис за миграцията, преди да представи конвертирания документ като еквивалентен на този входен файл.

REQ-FMT-005: Процесорът за обработка без загуба на данни ТРЯБВА да запази неизвестните елементи с разширение и неизвестните непроменени елементи, или да спре и да съобщи точно кои данни биха били загубени.

4. Обхват

Настоящата спецификация определя:

• представяне на логическото състояние на ръкописа в формат „JSON“ в един ред;
• идентифициране на формата и договаряне на версията;
• общи правила за JSON, низове, числа, времеви отметки, езикови етикети, URI и идентификатори;
• основните полета в ръкописите и общоприетите стандарти за преносими колекции;
• подредена секционна и блокова структура;
• връзки между научните обекти, към които може да се осъществи препратка;
• метаданни и препратки за логическите активи;
• незадължителен обмен на история в режим „inline“;
• поведение на производителя, потребителя, валидатора, мигратора и при обработката без загуба;
• структурни, референциални, семантични, профилни и политически слоеве за валидиране;
• диагностични записи, подходящи за машинно четене;
• пространствата на имена на разширенията и обработката на неизвестни полета;
• детерминистична сериализация и опционална канонизация;
• отчети за съвместимост и миграция;
• изисквания за сигурност, поверителност, съхранение, достъпност и интернационализация.

4.1 Извън обхвата

Настоящата спецификация не определя:

• физическият контейнер „.omi“ или ZIP-файлът;
• пътища към пакети, компресиране, контролни суми, подписи или криптиране;
• схема на база данни или реализация на хранилище за събития;
• състоянието на редакционния компонент, състоянието на избора, стековете за отмяна, кеш паметите или данните от сесията;
• геометрията на страницата, разбиването на страници, преносите на редове или стилистиката на публикацията;
• пълната семантика на раздели, блокове, участници, цитати, анотации или редакции;
• протокол за сътрудничество в реално време;
• политика за контрол на достъпа;
• политика за възстановяване на активи от разстояние;
• универсален формат на дървовидна структура за редактиране на текст с форматиране;
• PDF, HTML, EPUB, DOCX, JATS XML, Crossref XML или сериализация по DataCite XML.

Тези изисквания са определени в съответните спецификации на „OMI“ за семантика, работни потоци, публикуване, „API“ или контейнери.

5. Терминология

Прилага се документът „OMI Terminology and Definitions“.

5.1 Документ от ръкописа „OMI“

UTF-8 документ от типа „JSON“, чиято стойност на най-високо ниво е обект, чиято стойност „omi.format“ е „manuscript“ и чиято декларирана версия на формат се регулира от настоящата спецификация.

5.2 Версия на формата

Семантичната версия, посочена на omi.version, която определя правилата за файловия формат и схемата. Тя не е версия на ръкописа, версия на приложението, версия на пакета „OMI“, версия на контейнера или издание на публикацията.

5.3 Основен член

Член на обект от типа „JSON“, дефиниран в настоящата спецификация или в спецификацията „OMI“, посочена на адрес omi.specifications.

5.4 Удължителен елемент

Елемент в обекта „extensions“, чието име е абсолютен URI или URN на пространство от имена и чиято стойност се контролира от собственика на това пространство от имена.

5.5 Неизвестен член

Елемент, който даден процесор не разпознава. Елементът може да е познат на формата, но да е непознат за по-стара реализация.

5.6 Адресируем обект

Ръкописен обект с идентификатор „id“, към който може да се прави независима препратка, включително раздел, блок, анотация, цитат, библиографска записка, ресурс, агент, принос, „tombstone“ или редакция.

5.7 Моментална снимка

Една представена версия на ръкописа. Дадена снимка може да идентифицира редакцията, която тя представя, но сама по себе си не означава пълна верига от редакции.

5.8 Първоначални данни

Точната последователност от байтове, която се приема от потребител или мигратор преди анализиране, поправка, нормализиране или преобразуване.

5.9 Карантина

Състояние, при което дадена реализация запазва даден документ, но не го третира като успешно импортиран, редактируем или изпълним файл.

6. Принципи на проектирането

Форматът на файла се придържа към следните принципи:

1. Семантичен източник: ръкописът е източник за публикации, а не запис на конкретно оформление на страница.
2. Явна идентичност: идентичностите на формат, схема, ръкопис и адресируем обект никога не се извеждат само въз основа на името на файла.
3. Проверяемо представяне: основният документ е обикновен UTF-8 JSON.
4. Независимост при изпълнението: преносимото състояние изключва специфичното за редактора състояние по време на изпълнение и състоянието на акаунта.
5. Многостепенна валидация: синтаксисът, структурата, препратките, семантиката, профилите и локалната политика са разграничими.
6. Съвместимост с бъдещи версии при запазването: неизвестните данни се изолират, запазват и никога не се преинтерпретират без предупреждение.
7. Миграция с доказателства: преобразуването е явно, възпроизводимо и отчита загубите.
8. Разделяне на контейнерите: семантиката на логическата „JSON“ не зависи от структурата на архива.
9. Стабилна идентичност на обектите: препратките използват идентификатори, а не позицията при визуализация или индекса в масива.
10. Безопасно по подразбиране: при анализа не се изпълнява съдържанието и не се изтеглят външни ресурси без предупреждение.

7. Общ преглед на модела

Един документ от типа „OMI“ се състои от пет логически области:

Област	Представителни членове	Цел
Идентификация	schema, omi	Избира този формат, версия, профили и свързаните с тях спецификации
Състояние на ръкописа	id, locale, title, sections	Отразява настоящото състояние на научните изследвания
Свързани обекти	agents, contributions, annotations, citations, assets	Съдържа адресируеми поддържащи обекти и връзки
История	versioningModelVersion, headRevisionId, revisionHistory	По избор обменя информация за промените
Разширения	extensions	Съдържа данни извън основния набор, организирани в пространства от имена

Коренният обект представлява един логически документ. Контейнерът може да изведе избрани колекции в отделни части само когато „OMI-SPEC-330“ определя как тези части се събират отново в същия логически модел. При събирането отново значението на документа НЕ ТРЯБВА да се променя.

8. Общи правила за представяне

8.1 JSON и кодиране на символите

REQ-FMT-006: Документът в формат „OMI“ ТРЯБВА да бъде валиден JSON, кодиран в UTF-8. Създателите НЕ ТРЯБВА да включват маркер за реда на байтовете. Потребителите МОГАТ да приемат маркер за реда на байтовете с цел възстановяване, но ТРЯБВА да изведат предупреждение.

REQ-FMT-007: Имената на членовете на обектите от типа „JSON“ ТРЯБВА да бъдат уникални в рамките на всеки обект. Потребителят ТРЯБВА да открие дублиращите се имена преди или по време на анализа и НЕ ТРЯБВА да прилага без предупреждение правилото „първият печели“ или „последният печели“.

REQ-FMT-008: Стойността на най-високо ниво „JSON“ ТРЯБВА да бъде обект. JSON null, масиви, низове, числа и булеви величини не са допустими като стойност на най-високо ниво.

REQ-FMT-009: Строките ТРЯБВА да съдържат валидни скаларни стойности в Unicode. Производителите НЕ ТРЯБВА да генерират несдвоени сурогатни кодови точки в UTF-16.

Редът на елементите в обект няма семантично значение. Редът в масива има семантично значение, освен ако спецификацията „OMI“, която го дефинира, изрично не посочва, че масивът е безред.

8.2 Числа

REQ-FMT-010: Производителят НЕ ТРЯБВА да излъчва „NaN“, положителна или отрицателна безкрайност, нито друг числови токен, различен отJSON.

REQ-FMT-011: Цело число, представено като число от типа „JSON“, ТРЯБВА да попада в обхвата за оперативна съвместимост от -(2^53)+1 до (2^53)-1. Стойност, изискваща по-голяма точност, ТРЯБВА да бъде представена като низ, чиято семантика се определя от съответното поле.

Точните идентификатори, контролните суми, десетичните величини, указателите на страници и външните числови кодове ТРЯБВА да бъдат символни низове, освен ако съответната спецификация изрично не изисква числа от типа „JSON“.

8.3 Стойности „наличие“, „null“ и „празни“

REQ-FMT-012: Липсата означава, че дадена стойност не е посочена или не е приложима. Параметърът „null“ ТРЯБВА да се използва само когато управляващата схема изрично го позволява. Празен низ НЕ ТРЯБВА да се използва като заместител на липсваща задължителна стойност.

Празен масив означава известна празна колекция. Производителят ТРЯБВА да генерира празен масив за задължителна колекция без елементи и ТРЯБВА да пропусне незадължителна колекция, чието състояние е неизвестно или не е представено.

8.4 Времеви отметки

REQ-FMT-013: Полето за времева марка, регулирано от настоящата спецификация, ТРЯБВА да бъде дата и час съгласно RFC 3339 с изрично посочен UTC-координат или числово отклонение. За даден момент НЕ СЕ РАЗРЕШАВА да се използва дата без часова зона.

Производителите ТРЯБВА да подават времеви отметки в UTC с главни букви: T и Z. Потребителите ТРЯБВА да сравняват анализираните моменти, а не необработените низове с времеви отметки.

8.5 Езикови етикети

REQ-FMT-014: Полето за език ТРЯБВА да използва правилно форматиран езиков таг съгласно BCP 47. При таговете не се прави разлика между главни и малки букви; създателите СЛЕДВА да използват препоръчания вариант на изписване, без да променят значението на тага.

8.6 URI

REQ-FMT-015: Поле, дефинирано като URI, ТРЯБВА да съдържа абсолютен URI, освен ако съответното поле изрично не позволява относителна препратка. Потребителят ТРЯБВА да преобразува относителните препратки единствено спрямо изрично деклариран базов URI.

8.7 Идентификатори

REQ-FMT-016: Всеки адресируем обект ТРЯБВА да има непрепразен низ „id“. Идентификаторът ТРЯБВА да бъде уникален в рамките на обхвата на идентичността на ръкописа и ТРЯБВА да остава непроменен, докато научният обект запазва своята идентичност.

REQ-FMT-017: Имплементацията НЕ ТРЯБВА да използва повторно идентификатора на изтрит обект за друг обект. Когато е декларирана проследимост на изтриването, идентификаторът ТРЯБВА да продължи да се представя чрез „tombstone“ или еквивалентно доказателство за историята.

Идентификаторите са непрозрачни. Потребителят НЕ ТРЯБВА да прави изводи за типа на обекта, собствеността, местоположението, реда на ревизиите или правата за достъп въз основа на начина, по който е написан идентификаторът.

9. Обект „Ръкопис“ от ниво „Root“

9.1 Задължителни членове

Профилът „Core Snapshot“ изисква следните членове с права на администратор:

Член	Тип	Кардиналност	Значение
schema	URI от тип „string“	1	Непроменлив идентификатор на схемата за тази версия на формата
omi	обект	1	Формат и пакет от зависимости
id	низ	1	Идентификационен номер на ръкописа
locale	низ	1	Основен езиков идентификатор по BCP 47
title	низ	1	Непразно заглавие на ръкописа
sections	масив	1	Подредени раздели от най-високо ниво
createdAt	низ	1	Момент на създаване
updatedAt	низ	1	Времето, когато състоянието, представяно от Instant, е било актуализирано за последен път

REQ-FMT-018: Производителят на Core Snapshot ТРЯБВА да генерира всеки задължителен коренен елемент и ТРЯБВА да отговаря на публикуваната схема, специфична за съответната версия.

REQ-FMT-019: updatedAt ТРЯБВА да представлява момент, равен или по-късен от createdAt. Програмата за валидиране ТРЯБВА да отчете семантична грешка, когато това не е така.

9.2 Препоръчителни и незадължителни елементи

За целите на оперативната съвместимост са дефинирани следните основни елементи. Подробната семантика на обектите им е описана в съответните спецификации на „OMI“.

Член	Тип	Ред	Бележки
subtitle	низ	н/д	Незадължителни субтитри
abstract	низ или преносим обект със съдържание	н/д	Резюме без оформление за публикуване
keywords	масив от низове	значим	Ред на автора, когато е посочен
agents	масив от обекти	без права за управление	Обекти „Identity“ от OMI-SPEC-150
contributions	масив от обекти	има значение, когато е деклариран редът на ролите	Връзки между агенти и обекти
tombstones	масив от обекти	не е в хронологичен ред, освен ако не е посочено друго	Доказателства за изтриване
annotations	масив от обекти	има значение, когато е зададен редът на представяне	Обекти за анотации от OMI-SPEC-130
bibliographicRecords	масив от обекти	не е по реда на цитиране	Записи от OMI-SPEC-220
citations	масив от обекти	има значение, когато е зададен редът на цитиране	Появявания от OMI-SPEC-210
citationClusters	масив от обекти	значими	Групирани цитати по ред
crossReferences	масив от обекти	има значение, когато е деклариран редът на представяне	Семантични вътрешни препратки
assets	масив от обекти	ред на изобразяване	метаданни за логическите ресурси
extensions	обект	н/д	Стойности на разширенията в пространствата от имена

REQ-FMT-020: Преносимите експортирани файлове НЕ ТРЯБВА да съдържат пароли, токени за достъп, токени за обновяване, идентификатори на сесии, частни ключове, неразкрити пътища към локалната файлова система или други идентификационни данни.

REQ-FMT-021: При износа на файлове за преносими устройства НЕ СЕ ДОПУСКА избраните от редактора елементи, курсорите, състоянието на прозореца за преглед, стековете за отмяна, кеш паметите, временните съобщения за валидиране или специфичните за акаунта настройки на потребителския интерфейс да се третират като канонично състояние на ръкописа.

9.3 Пример за плик

{
  "schema": "https://openmanuscript.org/schemas/omi-manuscript-0.2.schema.json",
  "omi": {
    "format": "manuscript",
    "version": "0.2.0",
    "profiles": ["core-snapshot"],
    "specifications": {
      "OMI-SPEC-100": "0.1.0",
      "OMI-SPEC-120": "0.1.0",
      "OMI-SPEC-140": "0.1.0"
    }
  },
  "id": "urn:uuid:d3c23cd5-ffb8-4f16-8db5-68e32fa78d82",
  "locale": "en",
  "title": "A portable manuscript",
  "sections": [],
  "createdAt": "2026-09-05T08:00:00Z",
  "updatedAt": "2026-09-05T08:00:00Z"
}

10. Идентифициране на формата и договаряне на версията

10.1 Идентификатор на схемата

За тази версия schema ТРЯБВА да има точно следната стойност:

https://openmanuscript.org/schemas/omi-manuscript-0.2.schema.json

REQ-FMT-022: Производителят ТРЯБВА да предостави неизменния каноничен URI на схемата за конкретната версия на формата. Той НЕ ТРЯБВА да предоставя динамичен URI от типа latest като авторитетен идентификатор на схемата.

Потребителят МОЖЕ да използва надеждно локално копие на схемата и НЕ ТРЯБВА да изисква достъп до мрежата само защото документът съдържа URI на схема по протокола HTTPS.

10.2 Плик „OMI“

Обектът „omi“ има следните елементи:

Член	Тип	Кардиналност	Правило
format	низ	1	Точна стойност manuscript
version	semantic-version (низ)	1	Точната версия на файловия формат, посочена от създателя
profiles	масив от низове	1	Един или повече декларирани профили за съответствие
specifications	обект	1	съответствие между идентификатора на спецификацията на OMI и точната версия
generator	обект	0..1	Неофициална идентификация на производителя

Регистрираните токени за профили във версия 0.2.0 са:

Токен	Профил
core-snapshot	Снимка на ядрото
history-exchange	History Exchange
lossless-round-trip	Загуба на качество при двупосочното предаване

REQ-FMT-023: omi.format ТРЯБВА да съвпада с manuscript, а omi.version ТРЯБВА да съвпада с точните правила, използвани за сериализиране на документа.

REQ-FMT-024: Файлът „omi.profiles“ ТРЯБВА да съдържа „core-snapshot“, НЕ ТРЯБВА да съдържа дублиращи се токени и ТРЯБВА да декларира всеки допълнителен профил, за чиито задължителни данни производителят твърди, че предоставя.

REQ-FMT-025: „omi.specifications“ ТРЯБВА да съпостави всяка приложима спецификация на „OMI“, използвана в документа, с точна семантична версия. НЕ СЕ РАЗРЕШАВА използването на диапазон, име на клон, преместващ се таг или идентификатор без версия.

Допълнителният обект „generator“ МОЖЕ да съдържа „name“, „version“ и „uri“. Потребителят НЕ ТРЯБВА да променя валидацията или нивото на доверие единствено поради посочването на конкретен генератор.

10.3 Управление на версиите

REQ-FMT-026: Потребител, който поддържа декларираната версия на формата, ТРЯБВА да използва схемата и правилата за тази версия, а не най-новата версия, известна на потребителя.

REQ-FMT-027: Потребител, който не поддържа обявената основна версия, ТРЯБВА да запази или да постави в карантина оригиналния вход и НЕ ТРЯБВА да представя документа като успешно импортиран редактируем ръкопис.

REQ-FMT-028: Потребител, който се сблъска с по-нова второстепенна версия или версия с корекции, МОЖЕ да продължи само ако декларираната политика за съвместимост го позволява. Той ТРЯБВА да запази неизвестните данни и да изведе диагностично съобщение, което идентифицира непроверената версия.

11. Структура на ръкописа

11.1 Раздели

sections е подредената последователност от раздели на най-високо ниво в ръкописа. Всеки раздел трябва да съдържа:

• id: идентификатор на стабилен обект;
• title: заглавие на раздел, което МОЖЕ да бъде празно само ако моделът на уставния документ допуска раздел без заглавие;
• blocks: подреден масив от блокове със съдържание.

Една секция МОЖЕ да съдържа role, language, children, extensions, както и полета, дефинирани от обявената версия на модела на документа.

REQ-FMT-029: Производителят ТРЯБВА да запази реда на секциите и блоковете. Потребителят НЕ ТРЯБВА да извежда авторитетен ред чрез сортиране на идентификатори или заглавия.

11.2 Блокове

Всеки блок изисква id и type. Блокът МОЖЕ да съдържа преносими content, структурирани data, подблокове, език, адресируеми котви, препратки към ресурси и разширения с пространство от имена.

Този файлов формат не прави дървото на форматиран текст, специфично за даден редактор, преносимо само защото е вградено като низ от типа „JSON“. Декларираната спецификация на модела на документа или пространството от имена на разширенията трябва да дефинира значението на content и data.

REQ-FMT-030: Съответстващият създател ТРЯБВА да сериализира научното съдържание, като използва преносимото представяне, избрано чрез omi.specifications, или декларирано разширение. Той НЕ ТРЯБВА да изисква от потребителя да стартира или инстанциира редакционната среда на създателя, за да възстанови научния текст и структурата му.

REQ-FMT-031: Когато процесорът не разпознае блок type, той ТРЯБВА да запази идентификатора на блока, реда му, суровата преносима стойност, подблоковете и разширенията съгласно профила „Lossless Round Trip“. Той НЕ ТРЯБВА без предупреждение да преобразува блока в празен параграф.

11.3 Сборници и източници

Достъпът до обектите в кореновите колекции се осъществява чрез id. Връзките използват полета за идентификатори, дефинирани от приложимата семантична спецификация, като например targetBlockId, sourceBlockId, targetId, citationIds, creatorAgentId или идентификатори на родителски версии.

REQ-FMT-032: Препратка, която трябва да бъде разрешена в рамките на същия документ, ТРЯБВА да идентифицира съществуващ обект от разрешен тип. Програмата за валидиране ТРЯБВА да сигнализира за неразрешена препратка или препратка с несъвместим тип.

REQ-FMT-033: Една препратка НЕ ТРЯБВА да използва индекс на масив, номер на визуализирана страница, позиция в пиксели или временно отместване в редактора като единствена постоянна цел.

Външна препратка МОЖЕ да остане неразрешена локално, когато полето, което я регулира, допуска абсолютен външен URI и документът декларира, че външното разрешаване е разрешено. Проверката за валидност НЕ ТРЯБВА да извлича този URI по подразбиране.

11.4 Активи

assets съдържа логически метаданни за двоични или външни ресурси. Всеки ресурс трябва да декларира, според случая:

• id;
• тип на медията;
• роля;
• разбираем за човека етикет или име на файл;
• размер;
• алгоритъм и стойност на контролната сума;
• метаданни за достъпност, като например алтернативен текст или препратки към транскрипции;
• относително спрямо контейнера или абсолютно местоположение, разрешено от приложимия профил.

REQ-FMT-034: Байтовете на бинарни активи НЕ ТРЯБВА да бъдат вградени като неограничени данни в формат base64 в основния документ на ръкописа. Авторът ТРЯБВА да изведе байтовете в отделен файл чрез OMI-SPEC-330 или да използва изрично декларирано разширение или профил с ограничения за размера.

REQ-FMT-035: Позоваването на ресурс ТРЯБВА да сочи към декларираните метаданни на ресурса или към изрично разрешен външен URI. Потребителите НЕ ТРЯБВА автоматично да извличат външен ресурс по време на анализа или валидирането.

12. Обмен на исторически знания

12.1 Полета за история

Документът, с който се декларира, че „history-exchange“ е:

• versioningModelVersion – за определяне на точната версия на OMI-SPEC-160;
• headRevisionId – идентифицира ревизията, представлявана от снимката на кореновата директория;
• revisionHistory, съдържащ преносимия обект с историята.

Обектът „revisionHistory“ изисква:

Член	Значение
completeness	complete, partial или shallow
rootRevisionId	Най-ранната представена версия или действителният корен
headRevisionId	Ревизия, представена чрез снимка на кореновата директория
revisions	Регистрите на ревизиите се регулират съгласно OMI-SPEC-160

Тя МОЖЕ да включва „omissionNotice“, клонове, набори от промени, моментални снимки, доказателства за целостта, уведомления за редактиране и разширения с пространства от имена.

REQ-FMT-036: headRevisionId, revisionHistory.headRevisionId и посочената ревизия на моменталната снимка ТРЯБВА да съвпадат.

REQ-FMT-037: Всеки идентификатор на ревизия, който се представя, ТРЯБВА да бъде уникален. Всеки родителски идентификатор ТРЯБВА да се разрешава в рамките на revisionHistory.revisions, освен ако completeness е partial или shallow и липсващата граница е изрично декларирана.

REQ-FMT-038: Документ, в който липсва историята на ревизиите, НЕ ТРЯБВА да претендира, че отговаря на профила „history-exchange“, и НЕ ТРЯБВА да подсказва, че моменталната снимка съдържа пълна провенциална информация.

12.2 Външно изведена история в контейнер

OMI-SPEC-330 може да съхранява историята в отделна част на контейнера. В такъв случай възстановеният логически документ ТРЯБВА да отговаря на изискванията на настоящия раздел, преди да бъде представен като документ за обмен на история. Манфестът на контейнера, а не произволен низ, обозначаващ кореновата пътека, определя откриването и целостта на частите.

13. Модел за синтаксичен анализ

Един съобразен потребител следва тези етапи в посочения ред:

1. да се запази оригиналният входящ материал в съответствие с местната политика за съхранение;
2. да се прилагат зададените ограничения за размера в байтове и за ресурсите;
3. да декодира UTF-8 и да отхвърля неправилно оформени байтови последователности;
4. да се извърши токенизация на JSON, като се откриват дублиращи се имена на членове на обекти;
5. изисква обект от най-високо ниво;
6. за избор на формат прочетете само файловете „schema“ и „omi“;
7. да договорите обявената версия и профилите;
8. изберете надеждна схема, специфична за дадената версия;
9. да се извърши структурна валидация;
10. да разрешава идентичности и препратки в рамките на документа;
11. да се извърши семантична валидация и валидация на профила;
12. да се определят поддържаните и неподдържаните разширения;
13. да разкрие, постави в карантина, отхвърли или премести документа в съответствие с изрично определена политика.

REQ-FMT-039: Анализът ТРЯБВА да не включва изпълнение на съдържание. Имената на елементи от типа „JSON“, стойностите на низовете, URI-адресите, фрагментите от маркировката, стойностите на разширенията и вградените изрази ТРЯБВА да се третират като данни, освен ако по-късен, изрично одобрен етап от обработката не определи друго.

REQ-FMT-040: Анализаторът ТРЯБВА да прилага определени от реализацията ограничения за броя байтове на входните данни, дълбочината на вграждане, членовете на обектите, дължината на масивите, дължината на низовете и диагностиката на агрегатите. Превишаването на дадено ограничение ТРЯБВА да доведе до генериране на диагностично съобщение и НЕ ТРЯБВА да води до получаване на привидно завършен текст.

REQ-FMT-041: При избора на схема ТРЯБВА да се използва надеждно съответствие между поддържаните стойности на omi.version и схемите. Парсерът НЕ ТРЯБВА да изтегля, изпълнява или се доверява на произволна схема само защото тя е посочена във входните данни.

14. Модел на сериализация

14.1 Изисквано поведение

REQ-FMT-042: Производителят ТРЯБВА да издава UTF-8 JSON, чиито schema, omi.version, профили и версии на зависимите спецификации точно описват сериализираното представяне.

REQ-FMT-043: При сериализацията ТРЯБВА да се запази семантично значимият ред на масива, стабилните идентификатори, целите на препратките, както и разграничението между липсващи, празни и изрично допустими нулеви стойности.

REQ-FMT-044: Производителят ТРЯБВА да пропусне състоянията, предназначени единствено за имплементация, както и тайните състояния, описани на REQ-FMT-020 и REQ-FMT-021.

При износа на данни в четим за човека формат СЛЕДВА да се използва отстъп от две интервали, край на ред LF и един заключителен LF. Потребителите НЕ ТРЯБВА да разглеждат празните символи, отстъпите, краищата на редовете или реда на елементите на обекта като семантични.

14.2 Детерминизъм и канонизация

Две сериализации могат да бъдат семантично еквивалентни, въпреки че се състоят от различни байтове. Производител, който твърди, че използва детерминистична сериализация, ТРЯБВА да документира как подрежда елементите на обекта и как представя еквивалентните стойности.

REQ-FMT-045: Дигестът или подписът върху JSON ТРЯБВА да декларира алгоритъма за канонизация, версията на алгоритъма, кодировката на символите и обхвата, който обхваща. Реализациите НЕ ТРЯБВА да сравняват като еквивалентни дигести, създадени съгласно различни или недекларирани правила за канонизация.

JSON Схемата за канонизация (JCS) МОЖЕ да се използва, когато са спазени ограниченията за входните данни. Обичайният обмен на данни по протокола „OMI“ не изисква използването на JCS и НЕ ТРЯБВА да нормализира авторските низове само с цел получаване на идентични байтове.

14.3 Запазване на Unicode

REQ-FMT-046: Процесорът за двупосочна обработка ТРЯБВА да запази скаларната последователност в Unicode на неизменения научен текст. Той НЕ ТРЯБВА без предупреждение да прилага нормализация в Unicode, транслитерация, преобразуване на регистъра, замяна на „умни“ кавички, сгъстяване на празни пространства или преобразуване на символите за край на ред в стойностите на съдържанието.

Производителят МОЖЕ да нормализира новосъздадените идентификатори или машинно управляваните маркери, когато приложимата спецификация предвижда такава нормализация.

15. Валидиране и обработка на грешки

15.1 Слоеве за валидиране

Валидирането е структурирано на слоеве, така че грешките да остават обясними:

Слой	Примери	Изискван резултат
Синтаксис	UTF-8, граматика на „JSON“, дублиращи се имена	Грешка при неуспех
Плик	Формат, версия, URI на схемата, профили	Грешка при неподдържана или несъвместима декларация
Структурни	Типове, задължителни полета, шаблони	Диагностика на схемата на JSON
Референтен	Дублиращи се идентификатори, липсващи цели, неправилни типове цели	Семантична диагностика
Семантика	Ред на времевите отметки, последователност на историята, инварианти на модела	Семантична диагностика
Профил	Липсващи полета в „Обмен на история“	Диагностика на профила
Разширение/политика	Неизвестно пространство от имена, локален размер или правило за поверителност	Предупреждение или грешка съгласно декларираната политика

REQ-FMT-047: Валидаторът НЕ ТРЯБВА да отчита даден документ като съответстващ, когато някое от приложимите нива съдържа диагностика за грешка.

REQ-FMT-048: Валидирането ТРЯБВА да бъде детерминистично при една и съща входна информация, поддържан набор от схеми, възможности за разширение, деклариран профил и конфигурация на политиката.

Публикуваната схема „JSON“ умишлено допуска наличието на някои неизвестни елементи с цел запазване на съвместимостта с бъдещи версии. Поради това самото успешно прилагане на схемата не представлява пълен резултат за съответствие.

15.2 Диагностичен обект

Машинно четимата диагностичен отчет ТРЯБВА да съдържа:

Член	Тип	Значение
code	низ	Стабилна реализация или диагностичен код от типа „OMI“
severity	низ	error, warning или info
instancePath	низ	JSON Показател към най-близката представена стойност
requirement	низ	Приложим идентификатор от типа „REQ-FMT-NNN“
message	низ	Разбираемо за човека обяснение
relatedIds	масив	Идентификатори на съответните ръкописи
details	обект	Незадължителни структурирани, несекретни доказателства

Пример:

{
  "code": "FMT-UNRESOLVED-REFERENCE",
  "severity": "error",
  "instancePath": "/annotations/0/targetBlockId",
  "requirement": "REQ-FMT-032",
  "message": "Annotation ann-1 targets missing block block-404.",
  "relatedIds": ["ann-1", "block-404"]
}

REQ-FMT-049: Проверяващият ТРЯБВА да посочи най-близкото подходящо място в текста и приложимото изискване за всяка грешка. Той НЕ ТРЯБВА да включва идентификационни данни или съдържание от ръкописа с ограничен достъп в диагностичните отчети, освен ако не е изрично разрешено.

15.3 Възстановяване и ремонт

Потребителят МОЖЕ да предложи ремонт като отделна услуга. Ремонтът не е проверка на валидността.

REQ-FMT-050: При операция по поправка е ЗАДЪЛЖИТЕЛНО да се запази оригиналният вход, да се изброят всички приложени промени, да се посочат съответният инструмент и версията му, както и да се провери валидността на поправения резултат. Поправеният документ НЕ ТРЯБВА да се представя като идентичен по байтове или еквивалентен по произход на изходния документ.

16. Разширения и неизвестни данни

16.1 Обект „Разширение“

Всеки обект МОЖЕ да съдържа елемент от типа „extensions“, ако схемата, която го определя, го позволява. „extensions“ е обект от типа „JSON“. Името на всеки елемент ТРЯБВА да бъде абсолютен HTTPS URI или URN, контролиран от автора на разширението.

Пример:

{
  "extensions": {
    "https://example.org/omi/extensions/lab-notebook/1": {
      "experimentId": "EXP-42",
      "replicate": 3
    }
  }
}

REQ-FMT-051: Неосновните преносими данни, създадени от производител, ТРЯБВА да бъдат поставени под extensions и да бъдат индексирани чрез URI или URN на абсолютно пространство от имена. Производителят НЕ ТРЯБВА да създава коренно свойство без пространство от имена, което би могло да влезе в конфликт с бъдещ елемент от основния набор.

REQ-FMT-052: Потребителят НЕ ТРЯБВА да присвоява основна семантика от OMI на неизвестно разширение. Той МОЖЕ да пренебрегне разширението при представянето или обработката, като същевременно го запази.

REQ-FMT-053: Валидаторът ТРЯБВА да предупреждава за неизвестни елементи без пространство от имена. Той НЕ ТРЯБВА да ги премахва в рамките на валидирането.

16.2 Обработка без загуба на данни

REQ-FMT-054: При профила „Lossless Round Trip“ процесорът ТРЯБВА да запази стойността „JSON“, съдържаща обекта, името на елемента и позицията в масива на всеки непроменен неизвестен елемент и разширение.

REQ-FMT-055: Ако дадена редакция направи запазването невъзможно, обработващият ТРЯБВА да спре, преди да се извърши презапис, или да поиска изрично разрешение след представяне на машинно-четим доклад за загуба.

Не се изисква запазване байт по байт на празните символи и реда на членовете на обектите, освен ако процесорът изрично декларира, че поддържа поведение с запазване на байтовете. Изисква се семантично запазване на неизвестната стойност на JSON.

17. Управление на версиите и миграция

17.1 Разлики между версиите

Реализациите ТРЯБВА да правят разграничение между:

• Версия на файловия формат: omi.version;
• URI на схемата: schema;
• зависими версии на модела: omi.specifications;
• ревизия на ръкописа или на моментална снимка: headRevisionId или поле за ревизия, дефинирано от модела;
• версия на контейнера: манифестът на OMI-SPEC-330;
• версия на приложението: omi.generator.version, ако е налична;
• издание или етикет на изданието: поле, дефинирано от модела на изданието.

REQ-FMT-056: Производителят НЕ ТРЯБВА да използва едно поле за версия като заместител на друга категория от предходния списък.

17.2 Регистър на миграцията

Записът за миграция трябва да съдържа:

Член	Значение
sourceFormatVersion	Точен вход omi.version
targetFormatVersion	Точен резултат omi.version
tool	Име и версия на Migrator
migratedAt	RFC 3339 instant
sourceDigest	Опционален дайджест с деклариран алгоритъм и обхват на канонизацията
steps	Подредени идентификатори на приложените трансформации
warnings	Нефатални неясни моменти
losses	Пропуснати, приблизителни или преинтерпретирани данни
extensionsPreserved	Запазени пространства от имена на разширенията
validation	Обобщения за валидирането на изходните и целевите данни

Записът може да се съхранява заедно с изходните данни, в оторизирано разширение за проследяване на произхода или в частта за проследяване на произхода на контейнера „OMI“.

REQ-FMT-057: Миграторът ТРЯБВА да бъде ясен и възпроизводим: при една и съща изходна и целева версия, версия на мигратора, опции и възможности за разширение РЕЗУЛТАТЪТ ТРЯБВА да бъде семантично еквивалентен, а стъпките на миграцията – в една и съща последователност.

REQ-FMT-058: Програмата за миграция НЕ ТРЯБВА да твърди, че преобразуването е без загуба на данни, когато полето „losses“ не е празно или когато неизвестни изходни данни са били изтрити.

17.3 Миграция от „0.1.0“

В черновата на „0.1.0“ не беше публикувана канонична схема и тя беше внедрена експериментално. Поради това миграцията към „0.1.0“ започва с откриване на профила на имплементацията, а не със сляпо преозначение.

Миграторът за представянето на прекурсора „Open Manuscript Studio“ трябва:

1. да се запазят оригиналните .omi.json байта;
2. да разпознава URI на старата схема https://openmanuscript.org/schemas/omi-manuscript-0.1.json;
3. добавете пакета „omi“ и точните версии на зависимостите;
4. заменете URI-то на схемата с неизменния URI 0.2;
5. да се премахват остарелите дубликати на вградени автори едва след като бъдат съпоставени с агенти и приноси или след отчитане на загубата;
6. да се разграничат полетата за редактиране на ръкописа от версията на формата;
7. да проверите препратките към раздели, блокове, бележки, цитати и история;
8. преместване на данните за реализацията, които не са от основно значение, в разширение с именован пространство;
9. да се провери дали резултатът отговаря на схемата и семантичните правила на „0.2“;
10. да създаде запис за миграция.

REQ-FMT-059: Промяната само на schema или omi.version не представлява миграция и НЕ ТРЯБВА да се представя като успешно преобразуване.

18. Интеграция на контейнери

Самостоятелното представяне „.omi.json“ и контейнерът „.omi“ имат различни типове медии и функции:

Представяне	Управляваща спецификация	Временен тип медия	Типично разширение
Logical manuscript JSON	OMI-SPEC-320	application/vnd.openmanuscript+json	.omi.json
Физически контейнер „OMI“	OMI-SPEC-330	application/vnd.openmanuscript.omi+zip	.omi

REQ-FMT-060: Контейнерът ТРЯБВА да посочи точната версия на „OMI-SPEC-320“, която регулира неговата логическа част от ръкописа. Потребителят на файловия формат НЕ ТРЯБВА да извлича пътеки към пакети или правила за компресиране, ако липсва обработка по стандарта „OMI-SPEC-330“.

REQ-FMT-061: При извеждането на данни в части на контейнера ТРЯБВА да се запазят същите логически идентичности, ред, препратки, пълнота на историята и стойности на разширенията, получени от самостоятелното представяне.

19. Оперативна съвместимост

19.1 Внос

Импортирането от DOCX, JATS, XML, TEI XML, HTML, Markdown или друг източник представлява преобразуване към семантиката на OMI, а не доказателство, че всеки елемент от източника има съответствие в OMI.

REQ-FMT-062: Вносителят ТРЯБВА да докладва пропуснати, приблизителни или специфични за конкретната реализация характеристики на източника и СЛЕДВА да запази информацията за произхода на изходния формат. Той НЕ ТРЯБВА да преобразува неразпознато научно съдържание в обикновен текст без предупреждение, когато това променя смисъла.

19.2 Износ

PDF, HTML, EPUB, DOCX, JATS XML, Crossref XML и DataCite XML са производни резултати. При тяхното създаване може да се използват профили на публикации, но производният формат НЕ ТРЯБВА да се превръща в авторитетна семантика на ръкописа само защото се появява в даден резултат.

REQ-FMT-063: Износителят ТРЯБВА да запази изходния ръкопис в формат „OMI“ или неизменна препратка към него при генерирането на публикационен формат със загуба на информация и СЛЕДВА да докладва за неподдържани функции на целевия формат.

19.3 Транспорт „API“

API може да пренася директно логическия ръкопис JSON. HTTP преговорите за съдържание, частичните актуализации, удостоверяването и едновременността са част от OMI-SPEC-310. Частичното представяне API не трябва да претендира, че е пълен документ .omi.json, освен ако не съдържа всички задължителни полета и не декларира съответния профил.

20. Сигурност, поверителност и целостност

20.1 Недостоверни входни данни

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

REQ-FMT-064: Потребителите ТРЯБВА да третират маркировките, URL адресите, формулите, шаблоните и полезните данни на разширенията като инертни данни по време на анализа. За визуализирането или активирането е необходима отделна стъпка за пречистване и оторизация, съобразена с контекста.

REQ-FMT-065: Потребителите НЕ ТРЯБВА да разшифроват мрежови URI адреси по време на валидирането, освен ако операторът изрично не разреши извличането им в рамките на ограничен списък с разрешени адреси, времево ограничение, ограничение на размера, политика за пренасочване и политика за поверителност.

20.2 Чувствителни данни

Ръкописите и историческите материали могат да съдържат непубликувани изследвания, лични данни, поверителна рецензия, редактиран текст, данни за местоположение или материали с ограничен достъп.

REQ-FMT-066: Производителят ТРЯБВА да приложи предвидения профил за разкриване на информация преди експортирането и НЕ ТРЯБВА да включва съдържание с ограничен достъп само защото то се намира в хранилището за създаване на съдържание или в историята на ревизиите.

REQ-FMT-067: Протоколите за валидиране и миграция ТРЯБВА да съдържат възможно най-малко цитирано съдържание от ръкописа и ТРЯБВА да спазват политиката за достъп на входните данни.

20.3 Честност

Самият файл „JSON“ не доказва авторството, автентичността или актуалността. Доказателствата за целостта изискват деклариран дигест и обхват на канонизацията; удостоверените подписи и контролните суми на контейнерите се регулират от съответните им спецификации.

REQ-FMT-068: Потребителят НЕ ТРЯБВА да представя валидност на схемата, контролна сума или самодеклариран генератор като доказателство за надеждно авторство.

21. Достъпност

Форматът на файла запазва семантичната информация и информацията за достъпността, необходима на средствата за визуализация; той не налага конкретен потребителски интерфейс.

REQ-FMT-069: Производителят ТРЯБВА да запази метаданните за езика, структурата на заглавията, реда на четене, алтернативния текст, надписите, структурата на таблиците, източника на уравненията, транскрипциите и другите данни, свързани с достъпността, които се поддържат от приложимия семантичен модел.

REQ-FMT-070: Производителят НЕ ТРЯБВА да кодира значението единствено чрез цвят, визуално разположение, шрифт или геометрия на страницата в основното състояние на ръкописа.

Валидаторите ТРЯБВА да диагностицират липсващи метаданни за достъпност, когато типът на обекта и избраният профил изискват наличието на тези метаданни. Диагностиката ТРЯБВА да обяснява как да се намери засегнатият обект, без да се възпроизвежда чувствително съдържание.

22. Интернационализация

OMI ръкописите могат да съдържат всякаква система за писане по стандарта „Юникод“, двупосочен текст, комбиниращи знаци, исторически азбуки и многоезично съдържание.

REQ-FMT-071: Производителят ТРЯБВА да запази оригиналния текст в Unicode и изричните метаданни за езика. Потребителят НЕ ТРЯБВА да приема, че текстът е написан с латиница, че посоката на писане е отляво надясно, че се използва ASCII пунктуация или че е написан на един-единствен език.

REQ-FMT-072: Сортирането според локалната настройка, преобразуването на регистъра, сегментирането, представянето на датите и представянето на числата НЕ ТРЯБВА да заменят запазената авторска стойност, освен ако това не бъде поискано в рамките на оторизирана научна редакция.

Метаданните за посоката ТРЯБВА да се представят само когато не могат да бъдат надеждно изведени от декларирания език и съдържанието. Имената на свойствата, управлявани от машината, и регистрираните токени остават в ASCII.

23. Примери и тестови набори за проверка на съответствието

Публикуваните мачове за тази версия са достъпни на /examples/omi-spec-320/0.2.0/.

В списъка на съоръженията са посочени:

• точната спецификация и схема;
• очаквана валидност;
• очаквани диагностични кодове за невалидни примери;
• целта на осветителното тяло.

Първоначалният комплект включва:

• минимален Core Snapshot;
• типичен документ от History Exchange с разширение в пространството на имената;
• документ, в който липсва версията на формата;
• документ, съдържащ дублиращ се идентификатор, по който може да се осъществи търсене;
• документ, съдържащ неразрешена цел на анотация;
• документ с обърнати времеви отметки за създаване и актуализация;
• документ с несъответстващи заглавия на страниците;
• документ, съдържащ забранено поле за удостоверение.

Програмата за валидиране на препратки към хранилището демонстрира проверки на схемата и избрани семантични проверки. Тя представлява доказателство за реализация, но все още не е пълен набор от формални тестове за съответствие. Реализациите ТРЯБВА да оценяват нормативните изисквания в настоящия документ, освен да преминават публикуваните тестови случаи.

24. Нормативни препратки

• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
• RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
• RFC 3339 — Date and Time on the Internet: Timestamps
• RFC 5646 — Tags for Identifying Languages
• RFC 6901 — JavaScript Object Notation (JSON) Pointer
• RFC 7493 — The I-JSON Message Format
• RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax
• JSON Schema Core, Draft 2020-12
• JSON Schema Validation, Draft 2020-12
• OMI Specification Registry
• OMI Versioning Policy
• OMI-SPEC-160 — Versioning and Change Model
• OMI-SPEC-180 — Validation Model (Reserved)
• OMI-SPEC-330 — Container Architecture

25. Информативни източници

• RFC 8785 — JSON Canonicalization Scheme
• RFC 6838 — Media Type Specifications and Registration Procedures
• RFC 6839 — Additional Media Type Structured Syntax Suffixes
• FAIR Guiding Principles
• OMI Architecture Map
• OMI Specification Style Guide

26. Състояние на изпълнението

Официалните данни за внедряването се съхраняват в „OMI Implementation Status Matrix“.

Към момента на публикуването на този проект:

• Схемата на „0.2“ (JSON) е публикувана на каноничния URI с версия;
• публикуват се първоначален набор от тестови случаи и валидатор за сравнение;
• Open Manuscript Studio извежда представяне на прекурсор от типа „.omi.json“, като използва непубликувания URI на схемата „0.1“;
• Studio все още не декларира съответствие с OMI-SPEC-320@0.2.0;
• не е проверен нито един пълен валидатор, разработен от трета страна, нито пък пълен набор от формални тестове за съответствие между различни реализации.

Самото преминаване на тестовете за схемата „JSON“ или на референтните фикстури не гарантира пълно съответствие.

27. Нерешени въпроси

Следните въпроси остават отворени за следващите версии:

1. да финализира избраното от основния модел на документа преносимо представяне в формат с богат текст;
2. да хармонизира схемите за пълна идентичност, анотации, цитиране, ресурси и история, в міра на усъвършенстването на съответните им спецификации;
3. да се реши дали временният тип носител на доставчика трябва да бъде регистриран или заменен;
4. да се определи официална таблица за съвместимост за всички второстепенни версии, предшестващи версия 1.0;
5. да публикува машинно-четима диагностична схема, споделена с OMI-SPEC-180;
6. да се добавят фиксатори „duplicate-member-name“ и „resource-limit“ в байт формат, които не могат да бъдат представени чрез обичайната сериализация „JSON“;
7. да се дефинират тестове за беззагубно двупосочно предаване между различни реализации;
8. да се определи кои възможности за разширения могат да бъдат обявени в плика „omi“;
9. да се съгласува реконструкцията на външните контейнерни части със следващия проект на „OMI-SPEC-330“;
10. да се дефинират профилите на архивната устойчивост и сигнатурата, без да се налага задължително използване на мрежова резолюция.

28. История на промените

Версия	Дата	Промяна
0.2.0	05.09.2026	Пренаписах черновия вариант, като използвах шаблона за канонична спецификация; отделих логическия формат от архитектурата на контейнера; дефинирах класове и профили за съответствие, стабилни изисквания, договаряне на версии, анализиране, сериализация, валидиране, разширения, обмен на история, миграция, сигурност, достъпност и интернационализация; публикувана е схема „JSON“ и първоначални фикстури.
0.1.0	04.07.2026	Първоначален проучвателен проект под каноничния идентификатор OMI-SPEC-320, прехвърлен от стария OMI-SPEC-011.

29. Благодарности

Настоящата спецификация включва данни за внедряването, извлечени от Open Manuscript Studio, както и работата на общността Open Manuscript Initiative в областите архитектура, управление на версиите, валидиране, идентичност, модел на документи и контейнери.