Skip to content

docs(core-spec): clarify model declaration vs. query scope of the expression language #536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jbonofre merged 2 commits into from
Oct 8, 2026
Merged

docs(core-spec): clarify model declaration vs. query scope of the expression language #536

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ff7d6c3
docs(core-spec): clarify model declaration vs. query scope of the exp…
christianeu-db Oct 8, 2026
b4a91aa
docs(core-spec): scope the Dialects enum to model declaration
christianeu-db Oct 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion core-spec/expression_language.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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 queried in the local dialect.

#### Comparison Table

Expand Down
9 changes: 8 additions & 1 deletion core-spec/spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
|---------|-------------|
Expand All @@ -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
Expand Down
Loading