[OSSIE][SIGMA] Add bidirectional Sigma Computing data model converter

[mattsenicksigma]

Summary

Adds converters/sigma, a bidirectional converter between Sigma Computing data model specs and Apache Ossie, following the same structure/tooling as the dbt and NVIDIA GSF converters (uv, the apache-ossie pydantic models).

• A real tokenizer + recursive-descent parser + ANSI SQL renderer for Sigma's spreadsheet-style formula language (ossie_sigma.sigma_formula), covering ~30 functions and all operators with nested-call support — not a regex classifier. Every expression always preserves the original Sigma formula verbatim in a new SIGMA dialect entry, guaranteeing lossless round-tripping regardless of translation coverage, alongside a best-effort ANSI_SQL translation.
• Sigma ⇄ OSI mapping for datasets, fields, relationships (including Sigma's two column-addressing schemes — modeled column id vs. raw inode-<file>/<PHYSICAL_COLUMN> warehouse references), and model-level metrics, with native Sigma ids preserved via custom_extensions so re-export reuses stable ids rather than minting new ones.
• Controls and named/static element filters are intentionally not modeled as OSI concepts (no portable equivalent — see converters/sigma/LIMITATIONS.md §1) but round-trip byte-for-byte via custom_extensions.
• Adds SIGMA to OSIDialect/OSIVendor (python/src/ossie/models.py), the core-spec schema/docs (core-spec/spec.md, core-spec/osi-schema.json), and a Sigma column in expression_language.md's cross-tool mapping tables.
• Fixes two small pre-existing gaps found while validating output against the repo's own tooling (documented in LIMITATIONS.md): core-spec/osi-schema.json was missing root-level dialects/vendors properties already present in the pydantic model, and validation/validate.py didn't skip SQL-syntax checking for SIGMA the way it already does for MDX/TABLEAU/MAQL.

See converters/sigma/LIMITATIONS.md for a full, honest accounting of design tradeoffs, known gaps (relationship resolution edge cases, table-calculation functions with no portable form, cross-dataset metrics with no Sigma equivalent, etc.), the testing strategy, and a self-assessment of likely review concerns.

Opening as a draft to gather early feedback on the approach (particularly the relationship-resolution strategy and the SIGMA dialect/vendor enum additions) before finalizing.

Test plan

• cd converters/sigma && uv sync && uv run pytest — 50 tests pass (formula parser unit tests, directional conversion tests, byte-for-byte round-trip tests for two synthetic fixtures, and a real-world-input test against examples/tpcds_semantic_model.yaml)
• Verified sigma-to-osi output validates cleanly against core-spec/osi-schema.json and validation/validate.py for both fixtures
• Re-ran python/, converters/dbt/, and converters/gsf/ test suites to confirm the shared enum/schema changes don't regress existing converters
• Feedback from a committer on the relationship-resolution approach and whether the SIGMA enum additions need a dev@ discussion or can proceed via normal PR review (see LIMITATIONS.md "Assessment: likelihood of upstream approval")

🤖 Generated with Claude Code

[mattsenicksigma]

A more human comment:

Looking to add a Sigma Data Model converter to the Ossie standard. I've implemented all required items of the Ossie spec along with some optionals.

Some limitations based on Sigma's specific semantic layer will include:

• Any non-ANSI convertable Sigma formula's will not be able to be represented as metrics. This is true if the non-ANSI component is at any level of nesting in the Sigma formula
• As a result of the above, a Sigma Dialect has been added here to represent any Sigma specific formulas and such
• id stability is required for Sigma Data Models to be maintained. Thus, I've added functionality to preserve id's for all Sigma elements -> if going from OSI to Sigma, an id is hashed. If the opposite, the Sigma generated id is preserved. Both paths will lead to stable id's moving forward for the Sigma Data Model
• Similar to Snowflake Semantic Views, Sigma Data Models give the option for a named filter (in Sigma-land this is a "control") -> would be interesting to make this part of the generic Ossie spec -> currently definable under the custom extension functionality
• Any Sigma presentation specific items are definable in the custom extension functionality for this converter
• This converter only allows for table elements -> there are other elements that can be in a data model but they are out of scope of the Ossie standard I believe (Things like custom python, etc.)
• data types are translated as faithfully as possible
• AI context can be set in a Sigma Data Model, but currently blocked by this being available to GET/POST in Sigma's REST API

Happy to try and promote convention for these things and/or be a part of talks on promotion of some things to the generic Ossie spec.