feat(core-spec): decouple core spec from specific vendors

core-spec/expression_language.md

@@ -705,6 +705,8 @@ Ossie implementations MAY support additional functions through dialect-specific
 
 The Ossie dialect should always be supported.  Other dialects MAY be ignored.  There is no guarantee that all different dialects for an expression will act the same, so implementations should be consistent with their dialect handling.  This means that if an Ossie model has an expression written in two dialects, the implementation should deterministically choose which dialect to use.  
 
+The `dialect` field is a free-form string; the core specification does not enumerate a closed set. For a non-normative catalog of dialects well-known tools use, see [extensions/dialects.md](../extensions/dialects.md).
+
 ### Declaring Dialect-Specific Expressions
 
 ```

core-spec/ossie-schema.json

@@ -37,13 +37,15 @@
   "$defs": {
     "Dialect": {
       "type": "string",
-      "enum": ["ANSI_SQL", "SNOWFLAKE", "MDX", "TABLEAU", "DATABRICKS", "MAQL", "BIGQUERY", "SIGMA", "THOUGHTSPOT", "DAX", "HOLISTICS_AQL", "OSSIE_SQL_2026"],
-      "description": "Supported SQL and expression language dialects"
+      "minLength": 1,
+      "examples": ["OSSIE_SQL_2026", "ANSI_SQL", "DB_DIALECT", "BI_EXPRESSION", "SEMANTIC_MODEL_EXPRESSION", "PROGRAMMING_LANGUAGE"],
+      "description": "Expression language a metric or field expression is declared in. Any non-empty string is accepted. OSSIE_SQL_2026 is the only dialect this specification defines; others are opaque to Ossie. See extensions/dialects.md."
     },
     "Vendor": {
       "type": "string",
-      "examples": ["COMMON", "SNOWFLAKE", "SALESFORCE", "DBT", "DATABRICKS", "GOODDATA", "WISDOM", "POWER_BI", "HEX"],
-      "description": "Vendor name for custom extensions. Any string value is accepted."
+      "minLength": 1,
+      "examples": ["COMMON", "BI_TOOL", "DB_VENDOR", "SEMANTIC_LAYER"],
+      "description": "Vendor name for custom extensions. Any non-empty string is accepted. See extensions/vendors.md."
     },
     "AIContext": {
       "description": "Additional context for AI tools",
@@ -86,7 +88,7 @@
         },
         "data": {
           "type": "string",
-          "description": "JSON string containing vendor-specific data"
+          "description": "Opaque string of vendor-specific data that Ossie carries but does not interpret"
         }
       },
       "required": ["vendor_name", "data"],
@@ -101,6 +103,7 @@
         },
         "expression": {
           "type": "string",
+          "minLength": 1,
           "description": "SQL or dialect-specific expression"
         }
       },
@@ -111,6 +114,11 @@
       "type": "object",
       "description": "Expression definition with multi-dialect support",
       "properties": {
+        "sql": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Primary, portable expression written in OSSIE_SQL_2026. When both this field and an OSSIE_SQL_2026 entry in `dialects` are present, this field is authoritative."
+        },
         "dialects": {
           "type": "array",
           "items": {
@@ -119,7 +127,10 @@
           "minItems": 1
         }
       },
-      "required": ["dialects"],
+      "anyOf": [
+        { "required": ["sql"] },
+        { "required": ["dialects"] }
+      ],
       "additionalProperties": false
     },
     "DataType": {

core-spec/spec.md

@@ -48,30 +48,18 @@ Standard enumeration values used throughout the specification.
 
 ### Dialects
 
-Dialects in which metric and field expressions can be declared.
-
-| Dialect | Description |
-|---------|-------------|
-| `ANSI_SQL` | Standard SQL dialect |
-| `SNOWFLAKE` | Snowflake SQL |
-| `MDX` | Multi-Dimensional Expressions |
-| `TABLEAU` | Tableau calculations |
-| `DATABRICKS` | Databricks SQL |
-| `MAQL` | GoodData MAQL (Multi-Dimensional Analytical Query Language) |
-| `BIGQUERY` | Google BigQuery (GoogleSQL) |
-| `SIGMA` | Sigma Computing's spreadsheet-style formula language |
-| `THOUGHTSPOT` | ThoughtSpot formula language |
-| `DAX` | Data Analysis Expressions (Power BI / Analysis Services) |
-| `HOLISTICS_AQL` | Holistics AQL (Analytical Query Language) |
-| `OSSIE_SQL_2026` | Ossie's portable SQL expression language, defined in `expression_language.md` |
-
-`OSSIE_SQL_2026` is the only dialect whose semantics this specification defines. The other values
-identify vendor or third-party expression languages. Ossie treats expressions in those dialects as
-opaque, and implementations MAY ignore them (see
-[Dialect Extensions](expression_language.md#dialect-extensions)). Registering a dialect makes it
-valid for declaring a model; it does not mean Ossie supports querying in that dialect (see
+The `dialect` field is a free-form string, allowing any expression language to be used
+without requiring changes to the core specification.
+
+`OSSIE_SQL_2026` is the only dialect whose semantics this specification defines (Ossie's
+portable SQL expression language, see `expression_language.md`). All other values identify
+vendor or third-party expression languages, which Ossie treats as opaque and implementations
+MAY ignore. Registering a dialect does not mean Ossie supports querying in it (see
 [Model Declaration vs. Querying](expression_language.md#model-declaration-vs-querying)).
 
+For a non-normative catalog of dialects well-known tools use, see
+[extensions/dialects.md](../extensions/dialects.md).
+
 ### Data types
 
 `DataType` declares the logical value type of a field or metric independently
@@ -310,15 +298,19 @@ The expression object supports multiple SQL dialects for cross-platform compatib
 
 ```yaml
 expression:
+  sql: "customer_id"  # Primary, portable OSSIE_SQL_2026 form
   dialects:
-    - dialect: ANSI_SQL  # Must be one of the dialects enum values
+    - dialect: ANSI_SQL  # Free-form string; OSSIE_SQL_2026 is the only dialect the spec defines
       expression: "customer_id"  # Scalar SQL expression
 ```
 
 **Key Points:**
 
 - Use scalar SQL expressions (no aggregations)
 - Can be simple column references (e.g., `customer_id`) or computed expressions (e.g., `first_name || ' ' || last_name`)
+- The optional top-level `sql` is the primary, portable form, written in OSSIE_SQL_2026
+- At least one of the top-level `sql` or `dialects` MUST be present; either MAY stand alone
+- If both the top-level `sql` and an `OSSIE_SQL_2026` entry in `dialects` are present, the top-level `sql` is authoritative and consumers MUST use it as the OSSIE_SQL_2026 form
 - Identifiers refer to columns of the dataset's `source`, not to other fields. See [Name Resolution](#name-resolution).
 - Multiple dialect versions can be provided for the same field
 
@@ -448,11 +440,14 @@ The expression object supports multiple dialects
 
 ```yaml
 expression:
+  sql: "SUM(order.sales) / COUNT(DISTINCT order.customer_id)"  # Primary, portable OSSIE_SQL_2026 form
   dialects:
   - dialect: ANSI_SQL  # Default
     expression: "SUM(order.sales) / COUNT(DISTINCT order.customer_id)"
 ```
 
+At least one of the top-level `sql` or `dialects` MUST be present; either MAY stand alone. When both a top-level `sql` and an `OSSIE_SQL_2026` entry in `dialects` are present, the top-level `sql` is authoritative.
+
 ### Examples
 
 **Simple Aggregation:**
@@ -589,70 +584,19 @@ custom_extensions:
 The `vendor_name` field is a free-form string, allowing any vendor or organization to
 define custom extensions without requiring changes to the core specification.
 
-The following are well-known examples:
-
-| Vendor | Description |
-|--------|-------------|
-| `COMMON` | Common/standard extensions |
-| `SNOWFLAKE` | Snowflake-specific attributes |
-| `SALESFORCE` | Salesforce/Tableau-specific attributes |
-| `DBT` | dbt-specific attributes |
-| `DATABRICKS` | Databricks-specific attributes |
-| `GOODDATA` | GoodData-specific attributes |
-| `HONEYDEW` | Honeydew-specific attributes |
-| `WISDOM` | WisdomAI-specific attributes |
-| `POWER_BI` | Microsoft Power BI-specific attributes |
-| `SIGMA` | Sigma Computing-specific attributes |
-| `THOUGHTSPOT` | ThoughtSpot-specific attributes |
-| `HEX` | Hex-specific attributes |
-
-### Examples
-
-**Snowflake Extension:**
-
-```yaml
-- vendor_name: SNOWFLAKE
-  data: '{
-    "warehouse": "ANALYTICS_WH",
-    "database": "PROD",
-    "schema": "PUBLIC"
-  }'
-```
+For a non-normative catalog of `vendor_name` values well-known tools use, see
+[extensions/vendors.md](../extensions/vendors.md).
 
-**Salesforce Extension:**
-
-```yaml
-- vendor_name: SALESFORCE
-  data: '{
-    "tableau_workbook_id": "sales_dashboard",
-    "einstein_enabled": true,
-    "crm_sync": {
-      "enabled": true,
-      "sync_frequency": "daily"
-    }
-  }'
-```
-
-**DBT Extension:**
+### Example
 
 ```yaml
-- vendor_name: DBT
-  data: '{
-    "project_name": "analytics",
-    "materialized": "table",
-    "tags": ["daily", "core"]
-  }'
+- vendor_name: DB_VENDOR
+  data: '{"some_setting": "value", "nested": {"option": true}}'
 ```
 
-**Databricks Extension:**
-
-```yaml
-- vendor_name: Databricks
-  data: '{
-    "default_catalog": "finance",
-    "default_schema": "gold"
-  }'
-```
+The `data` payload is an opaque string that Ossie carries but does not
+interpret. For vendor-specific extension examples and the known-vendor catalog,
+see [extensions/vendors.md](../extensions/vendors.md).
 
 ---
 

core-spec/spec.yaml

@@ -28,21 +28,8 @@ version: 0.2.0.dev0
 # Enumerations
 # Standard enums used throughout the specification
 
-# Supported expression language dialects
-# Auto-generated from ossie-schema.json ($defs.Dialect.enum).
-dialects:
-  - "ANSI_SQL"              # Standard SQL dialect
-  - "SNOWFLAKE"             # Snowflake
-  - "MDX"                   # Multi-Dimensional Expressions
-  - "TABLEAU"               # Tableau
-  - "DATABRICKS"            # Databricks SQL
-  - "MAQL"                  # GoodData MAQL (Multi-Dimensional Analytical Query Language)
-  - "BIGQUERY"              # Google BigQuery GoogleSQL
-  - "SIGMA"                 # Sigma Computing spreadsheet-style formula language
-  - "THOUGHTSPOT"           # ThoughtSpot formula language (not SQL)
-  - "DAX"                   # Data Analysis Expressions (Power BI / Analysis Services)
-  - "HOLISTICS_AQL"         # Holistics AQL (Analytical Query Language)
-  - "OSSIE_SQL_2026"        # Ossie portable SQL expression language (see expression_language.md)
+# The `dialect` field is a free-form string, not a closed set. OSSIE_SQL_2026 is
+# the only dialect this spec defines. See extensions/dialects.md.
 
 # Supported logical data types for fields and metrics
 # Auto-generated from ossie-schema.json ($defs.DataType.enum).
@@ -58,8 +45,8 @@ datatypes:
   - "DateTimeTz"            # Instant identified using offset or timezone context
   - "Opaque"                # Known type outside the portable vocabulary
 
-# Vendor name for custom extensions (free-form string)
-# Examples: "COMMON", "SNOWFLAKE", "SALESFORCE", "DBT", "DATABRICKS", "GOODDATA", "WISDOM", "POWER_BI", "HEX"
+# Vendor name for custom extensions (free-form string).
+# See the known-vendor catalog in extensions/vendors.md.
 vendor_name: string
 
 
@@ -230,9 +217,11 @@ fields:
     # Each field can have expressions in different dialects for portability
     # Can be a simple column reference or a complex scalar expression
     # Identifiers refer to columns of the dataset's source, not to other fields
+    # At least one of the portable `sql` or `dialects` must be present; either may stand alone
     expression:
+      sql: string  # Primary, portable OSSIE_SQL_2026 form, e.g., "customer_id", "first_name || ' ' || last_name"
       dialects:
-        - dialect: string  # Must be one of the values from 'dialects' enum above, Default: "ANSI_SQL"
+        - dialect: string  # Free-form string; OSSIE_SQL_2026 is the only dialect the spec defines
           expression: string  # SQL scalar expression, e.g., "customer_id", "first_name || ' ' || last_name", "UPPER(email)"
 
     # Optional: Dimension metadata
@@ -293,9 +282,11 @@ metrics:
     # Model-scoped metrics qualify them as dataset.field; dataset-scoped
     # metrics use unqualified field names
     # Metrics cannot reference other metrics
+    # At least one of the portable `sql` or `dialects` must be present; either may stand alone
     expression:
+      sql: string  # Primary, portable OSSIE_SQL_2026 form, e.g., "SUM(orders.sales)", "AVG(orders.amount)"
       dialects:
-        - dialect: string  # Must be one of the values from 'dialects' enum above, Default: "ANSI_SQL"
+        - dialect: string  # Free-form string; OSSIE_SQL_2026 is the only dialect the spec defines
           expression: string  # Full SQL expression with aggregate functions, e.g., "SUM(orders.sales)", "AVG(orders.amount)"
 
     # Optional: Human-readable description of the metric

docs/index.md

@@ -59,7 +59,7 @@ The Ossie core specification (current version: **0.2.0.dev0**, latest released:
 | **Custom Extensions** | Vendor-specific metadata stored as JSON, allowing platforms to carry additional information without breaking core compatibility. |
 | **AI Context** | Optional annotations at every level (model, dataset, field, relationship, metric) to help AI tools understand business meaning — including instructions, synonyms, and example queries. |
 
-The specification supports multiple SQL dialects (`ANSI_SQL`, `SNOWFLAKE`, `DATABRICKS`, `MDX`, `TABLEAU`) so that expressions can be tailored to each platform while maintaining a common model structure.
+An expression carries a primary, portable form in `OSSIE_SQL_2026` and may also carry vendor-specific variants. The `dialect` label is a free-form string, so expressions can be tailored to any platform while maintaining a common model structure.
 
 For the full specification, see [core-spec/spec.md](../core-spec/spec.md). For validation tooling, see [validation/validate.py](../validation/validate.py). For a complete example, see the [TPC-DS semantic model](../examples/tpcds_semantic_model.yaml).
 
@@ -195,20 +195,19 @@ A typical Ossie-based workflow looks like this:
 
 ### Multi-Dialect Expression System
 
-A key architectural feature of Ossie is its multi-dialect expression system. Fields and metrics can carry expressions in multiple SQL dialects simultaneously:
+A key architectural feature of Ossie is its multi-dialect expression system. An expression carries a primary, portable form in `OSSIE_SQL_2026`, and fields and metrics can also carry vendor-specific variants in multiple dialects simultaneously:
 
 ```yaml
 expression:
+  sql: LOWER(email)                 # primary, portable OSSIE_SQL_2026 form
   dialects:
-    - dialect: ANSI_SQL
-      expression: LOWER(email)
     - dialect: SNOWFLAKE
       expression: LOWER(email)::VARCHAR
     - dialect: DATABRICKS
       expression: lower(email)
 ```
 
-This allows a single semantic model to be consumed natively by different platforms without expression translation. Each converter selects the dialect that matches its target platform, falling back to `ANSI_SQL` when a platform-specific dialect is not available.
+This allows a single semantic model to be consumed natively by different platforms without expression translation. Each converter selects the dialect that matches its target platform, falling back to the portable `OSSIE_SQL_2026` form when a platform-specific dialect is not available. The `dialect` label is a free-form string; `OSSIE_SQL_2026` is the only dialect Ossie defines, and all others are opaque.
 
 ---
 
@@ -251,7 +250,7 @@ Through `custom_extensions`. Each vendor can store arbitrary JSON metadata in ex
 In the expression, only a model-scoped metric can — it uses multi-part `dataset.field` references and combines datasets. A dataset-scoped metric's expression stays within its own dataset. See [Metric Scoping](https://github.com/apache/ossie/blob/main/core-spec/spec.md#metric-scoping).
 
 **What SQL dialects are supported?**
-The current specification supports `ANSI_SQL`, `SNOWFLAKE`, `DATABRICKS`, `MDX`, and `TABLEAU`. New dialects can be proposed through the standard specification change process.
+The `dialect` label is a free-form string, so any dialect can be used without a specification change. `OSSIE_SQL_2026` is the only dialect Ossie defines; all others are opaque and an implementation MAY ignore them. For a non-normative catalog of dialects well-known tools use, see [extensions/dialects.md](../extensions/dialects.md).
 
 ---
 
@@ -320,8 +319,8 @@ A practical guide for organizations looking to adopt Ossie.
 | **Dimension** | A categorical attribute used to slice and filter data (e.g., region, product category, date). In Ossie, dimensions are represented as fields with optional metadata such as `is_time`. |
 | **Metric** | A quantitative measure computed by aggregating fields (e.g., total revenue, average order value). A dataset-scoped metric is defined on an individual dataset, for a measure that semantically belongs to it and is evaluated at the dataset's row level; a model-scoped metric is defined at the model root and may span datasets. |
 | **Relationship** | A foreign key connection between two datasets, defining how they can be joined. Relationships are always many-to-one (from the referencing dataset to the referenced dataset). |
-| **Dialect** | A specific SQL or expression language variant (e.g., `ANSI_SQL`, `SNOWFLAKE`, `DATABRICKS`). Ossie supports multiple dialects so expressions can be tailored to each platform. |
-| **Custom Extension** | Vendor-specific metadata attached to any Ossie construct as a JSON string. Extensions allow platforms to carry additional information without modifying the core specification. |
+| **Dialect** | A SQL or expression language variant an expression is written in (e.g., `ANSI_SQL`). A free-form string; `OSSIE_SQL_2026` is the only dialect Ossie defines, and all others are opaque. |
+| **Custom Extension** | Vendor-specific metadata attached to any Ossie construct as an opaque string. Extensions allow platforms to carry additional information without modifying the core specification. |
 | **AI Context** | Optional annotations on any Ossie construct (model, dataset, field, relationship, metric) that provide additional context for AI tools — including natural language instructions, synonyms, and example queries. |
 | **Converter** | A tool that translates between the Ossie format and a specific vendor's semantic model format. Converters come in pairs: import (vendor → Ossie) and export (Ossie → vendor). |
 | **Hub-and-Spoke** | The architectural pattern used by Ossie, where the specification acts as the central format (hub) and vendor converters act as spokes, avoiding the need for point-to-point integrations. |

examples/tpcds_semantic_model.yaml

@@ -309,6 +309,8 @@ datasets:
 
       - name: customer_full_name
         expression:
+          # Primary, portable OSSIE_SQL_2026 form
+          sql: c_first_name || ' ' || c_last_name
           dialects:
             - dialect: ANSI_SQL
               expression: c_first_name || ' ' || c_last_name