xsdcpp codegen fails: cannot resolve group oreTradeData

Running ./projects/ores.codegen/scripts/xsdcpp_generate_ore.sh with the local /home/marco/Development/xsdcpp/build/src/xsdcpp binary (xsdcpp 1.0.3) against external/ore/xsd/input.xsd fails:

error: Could not find group 'oreTradeData'

Confirmed via a clean A/B test (git stash the external/ore/xsd/ sync, re-run, restore) that this happens identically against BOTH the external/ore/xsd/input.xsd content already committed on main before this session's ORE version bump AND the freshly-synced 1.8.16.0 version – so this is a pre-existing local environment/tool-version issue, not something the vendored XSD content update introduced. The group is defined (external/ore/xsd/instruments.xsd:6, <xs:group name"oreTradeData">=) and referenced correctly through the same import chain xsdcpp's own log shows it walking (input.xsd -> instruments.xsd -> … -> historicalreturnconfig.xsd, erroring right after) – looks like a genuine resolution bug in this xsdcpp build, or a version mismatch between this local xsdcpp checkout and whatever version last successfully generated the projects/ores.ore/include/ores.ore/domain/domain.hpp=/=domain.cpp currently committed on main.

Blocks regenerating ores.ore's domain types after external/ore/xsd/ is refreshed (see the IR curve seed-data capture-adjacent work: the ORE Engine binary/examples/XSD version-bump task). Left projects/ores.ore/include/ores.ore/domain/domain.hpp and domain.cpp UNCHANGED (still generated from the pre-bump schema) rather than attempt a workaround – xsdcpp is a separate tool/repo (~/Development/xsdcpp), not something to patch blind. Needs either rebuilding xsdcpp from its current upstream source (this local build may predate a fix), or investigating the group-resolution bug directly in xsdcpp's own source if it's still broken on a fresh build.

• Error reproduction: ./projects/ores.codegen/scripts/xsdcpp_generate_ore.sh (needs xsdcpp on PATH)
• Group definition: external/ore/xsd/instruments.xsd:6
• Group references: external/ore/xsd/input.xsd (x3), external/ore/xsd/referencedata.xsd:224
• Local xsdcpp checkout: ~/Development/xsdcpp (xsdcpp --version reports 1.0.3)
• Consumer: projects/ores.ore/include/ores.ore/domain/domain.hpp, projects/ores.ore/src/domain/domain.cpp

• xsdcpp — the tool, its pin, and how the bindings are generated.

Fixed, and the regeneration has been done. The local checkout now carries a two-pass group and substitution-group resolver in src/Reader.cpp, and the binary built with it resolves the full 23-file import chain. The bindings were regenerated on 2026-09-26: domain.cpp went from 108,655 lines to 40,095, domain.hpp from 13,507 to 16,266, the wrapper re-applied all 166 export annotations, every non-database ORE suite passed at 429,702 assertions in 516 cases, and the whole tree built.

Two things this capture got wrong in hindsight, worth recording. Its paths predate the regrouping of ores.ore into api, core and service, so the files it names no longer exist. And its own hypothesis was right: the local build did predate the fix.

The durable fix is the pin: the tool is a sibling checkout that no dependency file names, so its version is now recorded in the knowledge page above rather than in a backlog item.