Здравствуйте, r0nd, Вы писали:

R>С точки зрения вашей генерилки на основе XSD-схемы они все-таки разные.

Верно.
Логически это классы разных документов.
Но у них у всех есть одинаковый набор атрибутов.
Причем, в xsd есть общий базовый тип для них, и часть атрибутов объявлено в базовом типе.
А честь — нет, и хз почему...

R>Чем обусловлено ваше стремление "подружить" разные классы?

Весь этот зоопарк нужно сконвертировать в один класс dto.
Соответственно, с каждым классом чтение одних и тех же полей, одинаковым образом.

При этом, есть еще фишка.
Каждый квартал гос.учреждение выпускает обновление этих xsd.
Фактически, это новая версия и новый набор классов, каждые 3 месяца.
И как минимум одну предыдущую версию нужно поддерживать.

R>Предположу что находятся generated-sources?

Ээээ, наверно.

RB>>Классы авто-генерируются по xsd во время сборки.
RB>>Файлы xsd берутся с сайта гос-учреждения, корректировать невозможно.

R>Их можно локально добавить в resources. Чтобы обеспечить офлайн сборку без прямого соединения (из CI/CD например).

Ну, файлы xsd и выложены в resources.
CI/CD с сайта их не берет.

R>В Kotlin вы можете использовать интерфейсы и обобщенные функции, чтобы достичь подобного поведения, как в вашем примере на C++ с шаблонными функциями. Вам не нужно выносить общие поля в общий класс, и вы можете работать с классами, имеющими общие поля, используя интерфейсы и обобщенные функции.

Звучит, как то, что нужно.
Можете показать пример?

R>Следует помнить, что вы будете работать со своими объектами DTO (а не с экземплярами XSD-модели). Таким образом вы сможете дополнительно контролировать, если вдруг XSD-модель внезапмно изменится. В этом случае сборка просто не соберется (потому что мэппинг XSD-in-DTO не найдется) — и это будет сигнал об ошибке.

Ну, суть функционала в том и состоит, чтобы сконвертировать входное xml-сообщение во внутреннее представление (dto), и не зависеть от формата входных данных.