Address issues parsing XSD for ORE

[mcraveiro]

Summary

This PR fixes several issues that prevented xsdcpp from generating valid C++ code for complex XSD schemas like the Open Source Risk Engine (ORE) XSD files.

As per detail in #11.

Bug Fixes

• Handle abstract element references - Abstract elements without type attributes serve as placeholders for substitution groups. Previously, following a reference to such an element would fail with "Could not find 'element', 'complexType' or 'simpleType'". Now these references are properly recorded for later resolution.

• Handle elements without type definitions - Elements like <xs:element name="Type" maxOccurs="unbounded"/> without a type attribute should default to xs:anyType. Previously this caused an error; now it defaults to string type.

• Escape C++ reserved keywords - Extended the keyword escaping list to include bool, true, false, NULL, TRUE, FALSE, int, double, float, char, void, long, short, signed, unsigned, const, volatile, static, extern, register, auto, inline, virtual, explicit, friend, typedef, typename, template, namespace, using, public, private, protected, new, delete, this, return, if, else, switch, case, default, while, do, for, break, continue, goto, try, catch, throw, sizeof, alignof, typeid, noexcept, nullptr, constexpr, decltype, static_assert, thread_local, mutable, operator, asm, and linux.

• Handle duplicate enum values - When XSD enum values normalize to the same C++ identifier (e.g., 30E/360.ICMA and 30E/360 ICMA both become _30E_360_ICMA), append a counter suffix to make them unique.

• Support SimpleRefKind inheritance - Types inheriting from SimpleRefKind (typedef'd primitive types) now correctly use the xsd::base<> wrapper, similar to BaseKind and EnumKind.

• Fix duplicate struct members - Deduplicate elements when processing <xs:choice> branches to prevent duplicate struct members when the same element appears in multiple branches.

• Fix duplicate ElementInfo definitions - Track generated ElementInfo by C++ type name (not XSD type name) to avoid duplicates when multiple XSD types map to the same C++ type (e.g., nonNegativeInteger, positiveInteger, unsignedLong all map to uint64_t).

• Fix vector proxy issues - Added xsd::vector<bool> specialization using char storage to avoid std::vector<bool> proxy issues where .back() returns a proxy object instead of a reference.

• Improved error messages - Include the element name in error messages when type resolution fails.

New Features

• Separate output directories - New -H/--header-output and -C/--cpp-output options to place header files and implementation files in separate directories.

• Wrap namespace - New -w/--wrap-namespace option to wrap all generated code in an additional C++ namespace. Supports nested namespaces using :: syntax (e.g., -w myproject::xml).

• Skip inner namespace - New -N/--no-inner-namespace option to place types directly in the wrap namespace without the schema-derived inner namespace.

• GitHub Actions CI - Added .github/workflows/ci.yml for automated build and test on push/PR.

• ORE XSD test suite - Added test/ore/ directory with 23 XSD files from the Open Source Risk Engine project to validate code generation against a real-world complex schema.

• README documentation - Added "Command Line Options" section documenting all options with examples.

Test plan

• All existing tests pass (XmlParser_test, Reader_test, Generator_test, Features_test, XsdLib_test, Ecic_test, Ecoa_test)
• New Ore_test passes - validates code generation for complex ORE XSD schemas
• CI workflow runs successfully
• Generated code compiles with new namespace options

🤖 Generated with Claude Code

[mcraveiro]

Issues with ORE schema

I started adding roundtrip tests and picked up on the following issues:

  The XSD code generator (xsdcpp) has three main issues:
  Issue: Group references not expanded
  XSD Pattern: <xs:group ref="oreTradeData"/>
  Expected: 80+ trade data types
  Generated: Nothing
  ────────────────────────────────────────
  Issue: Substitution groups not handled
  XSD Pattern: <xs:element ref="nettingSetGroup"/>
  Expected: NettingSetId, NettingSetDetails
  Generated: Nothing
  ────────────────────────────────────────
  Issue: Unbounded in choice broken
  XSD Pattern: maxOccurs="unbounded" inside <xs:choice>
  Expected: xsd::vector<lgm>
  Generated: xsd::optional<lgm>
  Specific Gaps

  1. envelope.NettingSetId - Missing due to substitution group not resolved
  2. trade.{SwapData, FxForwardData, ...} - 80+ trade types missing due to group ref not expanded
  3. InterestRateModels.LGM - Should be vector, generated as optional

  Impact on Tests
  ┌────────────────┬────────┬────────────────────────────────────────────────┐
  │  Domain Type   │ Status │                 Blocking Issue                 │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ Portfolio      │ Fails  │ Missing NettingSetId, missing trade data types │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ Simulation     │ Fails  │ LGM should be vector not optional              │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ Conventions    │ Works  │ -                                              │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ CurrencyConfig │ Works  │ -                                              │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ TodaysMarket   │ Works  │ -                                              │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ PricingEngines │ Works  │ -                                              │
  ├────────────────┼────────┼────────────────────────────────────────────────┤
  │ CurveConfig    │ Works  │ -                                              │
  └────────────────┴────────┴────────────────────────────────────────────────┘

[craflin]

Many thanks for your massive contribution! I'll review and probably merge it soon.

[mcraveiro]

Thanks for looking into this. As far as I can see, the entire ORE schema is now parseable. My only concern at present is that we are generating massive header and implementation files, but I can't think of a good way around this. I was thinking perhaps of adding a clang based tool to post-process as a separate project - unless you can think of a better approach.

Cheers