Working notes on Apache Ossie. Syntax reference: core-spec/spec.md. Spec is 0.2.0.dev0, last release 0.1.1 (2025-12-11).
Discoveries
Converters prioritize vendor-specific dialects over ANSI_SQL. Gave a field three different dialect expressions (ANSI_SQL, SNOWFLAKE, DATABRICKS), each converter picked its own over the generic one.
Field-name collision across a direct relationship (Databricks flattens; Snowflake doesn’t). Same field name (customer_id) declared explicitly on both sides of a relationship, Databricks rejects it, Snowflake handles it fine.
Joins chain/nest, not flatten. A→B→C relationship chain produces a nested joins block in Databricks output, with dotted-path references (customers.regions.region_name) tracing the full chain.
Multiple custom_extensions vendors are allowed, but converters don’t use them yet. Added DBT, Databricks, and Snowflake extension blocks in one file, none of it showed up in either converter’s output, no error either, just silently dropped. Since the data never makes it into the vendor file at all, it can’t survive a round-trip back to Ossie either, there’s nothing left to read back.
ai_context.synonyms survives conversion, unlike custom_extensions. synonyms: [revenue, sales] on total_revenue showed up in both Databricks and Snowflake output, pulled straight from the source ai_context block. Direct counterpoint to the custom_extensions finding, not all metadata gets dropped, just some of it.
is_time handling diverges across converters. Snowflake keeps time dimensions in a separate time_dimensions: block; Databricks flattens them into regular dimensions: with no time marker at all. dbt also cares about this (its native reader wants an agg_time_dimension), so this is a three-way disagreement, not just two.
dbt’s output isn’t directly queryable, unlike Databricks and Snowflake. Databricks/Snowflake produce native objects, YAML you hand straight to the platform and query with plain SQL. dbt produces a compiled MetricFlow manifest, it needs MetricFlow’s own Python query engine at runtime to turn a metric request into SQL. Not a bug, a different consumption model entirely, and not something a future release changes.