From ff7d6c34a8f0e1e99f616f698d1495f0ea18474b Mon Sep 17 00:00:00 2001 From: Chris Eubank <108756251+christianeu-db@users.noreply.github.com> Date: Thu, 8 Oct 2026 02:56:12 +0000 Subject: [PATCH 1/2] docs(core-spec): clarify model declaration vs. query scope of the expression language core-spec/expression_language.md scopes the expression language to the logical layer (metrics, fields, filters) and already notes that the query interface is defined in a separate document, but the boundary between using the language to declare a model and using it to query one is easy to miss, because the same expressions reappear when a model is queried. Add a "Model Declaration vs. Querying" subsection to the Overview that states the distinction explicitly, and relocate the pre-existing sentence about the query interface being defined elsewhere out of the Namespacing section into it. This is an editorial clarification; no functions, dialect values, or compliance levels change. Co-authored-by: Isaac --- core-spec/expression_language.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/core-spec/expression_language.md b/core-spec/expression_language.md index 0ccb53c15..9ae0649d1 100644 --- a/core-spec/expression_language.md +++ b/core-spec/expression_language.md @@ -42,6 +42,15 @@ This document defines the SQL expression language subset that Ossie-compliant im We expect there will be extensions to this language to cover concepts such as sub-queries, grain calculations, etc. However, these will each have their own proposal. +### Model Declaration vs. Querying + +This expression language is scoped to *declaring* a model — authoring the logical layer's metrics, fields, and filters. It does not define a query interface. The two are distinct: + +* **Declaration** uses expressions to define what a model is. This document governs declaration. +* **Querying** evaluates a question against a declared model and returns rows. Query interfaces will be defined in separate documents. + +Consequently, the expressions defined here only declare a model: adding a dialect here does not mean Ossie supports querying with that dialect. + ### Design Principles 1. **Portability**: Core functions work identically across all implementations @@ -76,7 +85,7 @@ All identifiers MUST be valid names and follow ANSI SQL naming, with the size li Regular identifiers (unquoted) should be case insensitive. For example, an identifier id is regular, so it would match with Id or iD. Comparing quoted and non-quoted identifiers is DB specific, so for best portability it is best to use simple identifiers. -The quote character for the Ossie dialect will follow ANSI SQL and support the double quote character (“). This means that if an expression is in a field expression or as an identifier in the YAML, this will be the expected quoting. However, there are some databases that use other escape characters. Working with these have the option of either creating expressions using their dialect or having the Ossie document written in the Ossie dialect, but then having the SQL Interface queried in the local dialect. The SQL Interface will be defined in a different document. +The quote character for the Ossie dialect will follow ANSI SQL and support the double quote character (“). This means that if an expression is in a field expression or as an identifier in the YAML, this will be the expected quoting. However, there are some databases that use other escape characters. Working with these have the option of either creating expressions using their dialect or having the Ossie document written in the Ossie dialect, but then having the SQL Interface queried in the local dialect. #### Comparison Table From b4a91aae5f5158d0baf3a40c5115b62f972da669 Mon Sep 17 00:00:00 2001 From: Chris Eubank <108756251+christianeu-db@users.noreply.github.com> Date: Thu, 8 Oct 2026 16:10:40 +0000 Subject: [PATCH 2/2] docs(core-spec): scope the Dialects enum to model declaration Reword the Dialects enum lead in spec.md so that it describes declaration rather than general support, and add a note that OSSIE_SQL_2026 is the only dialect whose semantics the specification defines, that other dialects MAY be ignored, and that registering a dialect does not mean Ossie supports querying in it. Also drop the remaining reference to the "SQL Interface" from the identifier-quoting paragraph in expression_language.md. Co-authored-by: Isaac --- core-spec/expression_language.md | 2 +- core-spec/spec.md | 9 ++++++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/core-spec/expression_language.md b/core-spec/expression_language.md index 9ae0649d1..cc847e53a 100644 --- a/core-spec/expression_language.md +++ b/core-spec/expression_language.md @@ -85,7 +85,7 @@ All identifiers MUST be valid names and follow ANSI SQL naming, with the size li Regular identifiers (unquoted) should be case insensitive. For example, an identifier id is regular, so it would match with Id or iD. Comparing quoted and non-quoted identifiers is DB specific, so for best portability it is best to use simple identifiers. -The quote character for the Ossie dialect will follow ANSI SQL and support the double quote character (“). This means that if an expression is in a field expression or as an identifier in the YAML, this will be the expected quoting. However, there are some databases that use other escape characters. Working with these have the option of either creating expressions using their dialect or having the Ossie document written in the Ossie dialect, but then having the SQL Interface queried in the local dialect. +The quote character for the Ossie dialect will follow ANSI SQL and support the double quote character (“). This means that if an expression is in a field expression or as an identifier in the YAML, this will be the expected quoting. However, there are some databases that use other escape characters. Working with these have the option of either creating expressions using their dialect or having the Ossie document written in the Ossie dialect, but then queried in the local dialect. #### Comparison Table diff --git a/core-spec/spec.md b/core-spec/spec.md index 3b15c9928..cb82aa7e2 100644 --- a/core-spec/spec.md +++ b/core-spec/spec.md @@ -47,7 +47,7 @@ Standard enumeration values used throughout the specification. ### Dialects -Supported SQL and expression language dialects for metrics and field definitions. +Dialects in which metric and field expressions can be declared. | Dialect | Description | |---------|-------------| @@ -63,6 +63,13 @@ Supported SQL and expression language dialects for metrics and field definitions | `DAX` | Data Analysis Expressions (Power BI / Analysis Services) | | `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 +[Model Declaration vs. Querying](expression_language.md#model-declaration-vs-querying)). + ### Data types `DataType` declares the logical value type of a field or metric independently