10.3 IDL Structure Naming Principles [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== 10.3 IDL Structure Naming Principles ======

[[fxdemo:04-part:10-mapping-from-fx-logical-information-structures-to-idl-and-generated-types:start | Go To Mapping from FX Logical Information Structures to IDL and Generated Types ]]

IDL structure names should preserve a clear relationship to the FX logical information structure they realize.

IDL names should:

  * use stable, descriptive names;
  * preserve the FX domain context where helpful;
  * avoid implementation-only abbreviations when they obscure traceability;
  * align with DDS Topic and generated type naming conventions;
  * distinguish commands, acknowledgements, records, assertions, status reports, replay requests, and replay results; and
  * remain consistent with the Phase 0 Developer Handbook.

A recommended IDL structure naming pattern is:


  Fx<LogicalInformationStructureName>


Examples include:

  FxTransactionCandidate
  FxValidationResult
  FxSemanticAssertion
  FxContractState
  FxCashFlowObligation
  FxPolicyDecision
  FxReleasePackage
  FxAuditRecord
  FxProvenanceRecord
  FxNodeStatus
  FxControlCommand
  FxCommandAcknowledgement
  FxReplayRequest
  FxReplayResult


The IDL structure name is an implementation-level name. It does not redefine the FX logical information structure.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>