Кстати нет. Не тот случай. Это редкая ситуация когда это не ошибка дизайна

Я готов 90% своей работы признать ошибкой, но в данном случае м не это реально было бы очень полезно

Обрисуй тогда почему так надо

Я не буду критиковать решение чесслово

Когда я был маленький, я думал что хороши только структуры без внутренних (и тем более перекрёстных) ссылок, потому что они хорошо сериализуются и вообще.
А сейчас я часто делаю в чилд-нодах ссылки на парент-ноды, для обеспечения двусторонней связи. И получение нужного родителя обычно получается примерно как
auto p = this.parent;
while (!p.somefield) parent = p.parent;
Всё, мы получили нужного родителя в дереве. Время получать ID, или что там нужно, дабы не дублировать поле на каждого ребёнка. Правда, это потребует некоторого парсинга структуры для генерации дополнительных связей.

Вот представь XML документ с плавающей структурой. Которую ты заранее толком не знаешь. Тебе нужно из него не только вытянуть ряд полей которые там могут быть где угодно, но и эмулировать отсутствующие поля. Которые подразумеваются неявно.

Ну вот допустим у тебя есть структура
lots
 lot
 lot

У каждого лота есть номер. Но есть структуры у которых просто идет

lot

и номера лота нет, но тебе нужно обработать этот случай и сделать вид что номер лота есть ( чтобы не путать с остальными делаем его нулевым).

Или к примеру у тебя есть какая-то секция. Что в ней написано ты распарсить толком не можешь т.к. опять же структура слишком плавающая. Ты знаешь только примерные варианты ее нахождения. Но тебе нужно ее свести к какому-то флагу булеву. Типа скорее всего тут какой-то отказ идет.

Ну и далее в определенные лоты нужно заинджектить определенные значения которые из справочника берутся. Отсюда задача про "вставить в непустые блоки значения".

Как-то оно так. Может звучит страшно, но реальность такова что данные именно такие

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

Просто потому что в едином формате работать удобнее всего.

я не против появления очередного qml)

Но это же не означает необходимость менять изначальную структуру

Я морфологию на первом этапе анализирую чтобы хоть как-то понять что за документа и на что он больше похож

В плане? Файлы ж из внешних источников

Вот это и есть то что я описал, только на более высоком уровне.

1. Выбираем конкретный комплект парсеров на основании типа документа
2. Разбиваем документ на блоки, парсером блоков выбранным на предыдущем этапе
3. Парсим блоки, выбирая конкретный парсер блока исходя из морфологии блока.
4. ?????
5. Получаем гомогенный список любой чуши, которую можно хоть как-то структурировать

да это уже пройденный этап это +\- у меня готово и работает

Ну ты конвертируешь (создаёшь новую структуру), сразу же по месту и учитывай что некоторые значения могут не существовать. Впрочем, так может быть и правда сложнее.

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

Ящитаю, что проще сделать комплект парсеров, ибо проще писать, проще править — если где-то что-то изменилось — ты видишь в каком конкретно участке вылезают косяки, не надо городить один сверхсложный инструмент "для всего", обойдясь несколькими простыми инструментами для частностей.

Отчасти я согласен. Отчасти нет. Мне промежуточное представление нужно для того чтобы я мог какие-то нестандартные действия выполнять не будучи привязанным к жестко к структуре

оно у тебя и выглядит, как какой-то хмл. Такие же xpath запросы, выбрать ноды, сделать то-то.

@DmitryBubnenkov  друг интересуется в каких сферах юзал red кроме той попытки написать драйвер бд на system?

Неее