/skd-decompile - Декомпилятор СКД в JSON DSL

Принимает XML схемы компоновки данных (корневой элемент DataCompositionSchema; в выгрузке EDT/Конфигуратора это обычно Template.xml макета) и генерирует JSON-черновик в формате DSL скила /skd-compile. Обратная операция к /skd-compile.

ВАЖНО: результат - ЧЕРНОВИК, не гарантированный lossless round-trip. Перед компиляцией через /skd-compile обязательно просмотреть JSON и разрешить все маркеры _todo.

Использование

/skd-decompile <Template.xml> [output.json]

Команда

powershell.exe -NoProfile -File skills/1c-skd-decompile/scripts/skd-decompile.ps1 -InputFile "<путь>/Template.xml" [-OutputFile "<путь>.skd.json"]

Параметры

Параметр	Обязательный	Описание
InputFile	да	Путь к XML СКД. Имя файла любое - проверяется только корневой элемент DataCompositionSchema
OutputFile	нет	Путь для JSON. По умолчанию рядом с входным: <имя>.skd.json

Коды возврата

Код	Условие
0	Успех (в том числе с предупреждениями _todo)
1	Ошибка: файл не найден, XML не парсится, корень не DataCompositionSchema
2	Неверные аргументы (python-версия, argparse)

Рабочий процесс

1. /skd-decompile - получить JSON-черновик из существующей СКД
2. Просмотреть черновик, разрешить каждый _todo (вручную или моделью)
3. Править JSON под задачу (новые поля, варианты, параметры)
4. /skd-compile - собрать новый Template.xml
5. /skd-validate и /skd-info - проверить результат

Легитимные сценарии: заготовка нового отчета на основе существующего как шаблона; структурный рефакторинг полей/вариантов. Для точечной правки одного отчета лучше /skd-edit - полный цикл переписывает весь макет.

Ограничения - черновик и маркеры _todo

• Конструкции XML, которые наш DSL не выражает, помечаются ключом "_todo" (массив строк-пояснений) на уровне соответствующего элемента JSON или корня. Каждая помета дублируется предупреждением в stderr.
• Перед скармливанием /skd-compile разрешить каждый _todo: перенести смысл в поддерживаемую форму или сознательно удалить (компилятор упадет на объектах-заглушках, состоящих из одного _todo).
• В _todo уходят (не полный список): составные типы значений и TypeSet, папки полей (DataSetFieldFolder), вложенные схемы (nestedSchema), условия выбора макета (templateCondition), ячейки-картинки, привязки макета к полю (fieldTemplate), пользовательские поля вариантов (userFields), scope условного оформления, GroupItemAuto в группировках, неизвестные типы элементов структуры/отбора/выборки.
• Молчаливые упрощения (без _todo на каждом узле): userSettingID структурных элементов отбрасываются (одна сводная помета в корне), userSettingID отборов в shorthand-форме заменяются флагом @user (при компиляции сгенерируется новый GUID), стиль ячеек макета подбирается эвристикой по 4 встроенным пресетам (header/data/subheader/total), ширины и высота макета читаются только из первой строки.
• dataParameters всегда выводятся явным массивом (свертка в "auto" не выполняется).
• Схема без единого dataSet декомпилируется, но помечается в корне: /skd-compile требует минимум один набор данных.
• py-версия строит глобальную карту namespace-префиксов документа (первое объявление префикса побеждает). На XML, где один и тот же префикс переиспользован с разными URI на разных уровнях (встречается у .NET-сериализаторов), возможен неверный резолвинг типов - для таких файлов используй ps1-версию (контекстный резолвинг по месту).

Примеры

# Декомпиляция макета отчета, JSON рядом (Template.skd.json)
powershell.exe -NoProfile -File skills/1c-skd-decompile/scripts/skd-decompile.ps1 -InputFile "src/Reports/Продажи/Templates/ОсновнаяСхемаКомпоновкиДанных/Ext/Template.xml"

# Явный путь вывода
powershell.exe -NoProfile -File skills/1c-skd-decompile/scripts/skd-decompile.ps1 -InputFile "C:/tmp/Schema.xml" -OutputFile "C:/tmp/schema-draft.json"

Альтернатива (Python, тот же алгоритм):

python skills/1c-skd-decompile/scripts/skd-decompile.py -InputFile "<путь>/Template.xml" [-OutputFile "<путь>.skd.json"]

JSON-схема DSL

Полная спецификация целевого формата: docs/skd-dsl-spec.md (прочитать через ). Краткий справочник - в skills/1c-skd-compile/SKILL.md.