You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ossie.apache.org by "justint-db (via GitHub)" <gi...@apache.org> on 2026/09/23 19:10:45 UTC
[PR] [core-spec] Add layered query interface overview [ossie]
justint-db opened a new pull request, #452:
URL: https://github.com/apache/ossie/pull/452
## Summary
Adds `core-spec/layered_query_interface.md`, a short overview document introducing the four-layer query model for readers navigating the individual layer specs:
- **Layer 1 — Common Expression Language**: the shared language used inside Ossie model definitions, establishing portability across engines (interchange concern)
- **Layer 2 — Relational Interface (SQL Measures)**: Layer 1 expressions extended with relational SQL constructs plus `MEASURE()` for grain-safe aggregation (open PR: #354)
- **Layer 3 — Wide Table Interface**: declarative flat-object query interface that compiles down to Layer 2 (open PR: #246)
- **Layer 4 — Ontology**: higher-order semantic concepts defined by the ontology working group
The document clarifies the distinction between the expression language as a model-definition/interchange concern (Layer 1) and the query languages exposed at each layer (which need not use the same language). It also covers how the layers compose, and links to the background proposals from Justin Talbot and Will Pugh.
## References
- Original layered interface proposal: [OSI Layered Query Interface](https://docs.google.com/document/d/1FOtRNBu6UqA2yeOwUa4jt1r2v45BWQJqS5_BTk34a1c/edit) (Justin Talbot, May 2026)
- Four-layer refinement: [Proposed Semantics Priorities](https://docs.google.com/document/d/1EgG5vOlJSubm01S1AGMJ4MKcMcjxBhJHenGKWMr849E/edit) (Will Pugh, August 2026)
This pull request and its description were written by Isaac.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "jbonofre (via GitHub)" <gi...@apache.org>.
jbonofre merged PR #452:
URL: https://github.com/apache/ossie/pull/452
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "christianeu-db (via GitHub)" <gi...@apache.org>.
christianeu-db commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250808341
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
+how they are queried.** Fan-out and chasm-trap errors cannot occur when measures are queried
+through this interface. The model's datasets are exposed as SQL relations; consumers query them
+with ordinary SQL, using `MEASURE()` in place of raw aggregates.
+
Review Comment:
Experimentally, we've found that BI tools have a much lower barrier to entry connecting to Layer 2 while preserving their existing feature sets.
We've started collecting [BI-generated SQL examples](https://github.com/apache/ossie/tree/main/bi-sql-examples) in the repository. BI tools generate fairly complex SQL (e.g. subqueries, joins, window functions) and generally assume that the objects they're querying behave like regular tables.
This creates two challenges when connecting directly to Layer 3:
- **SQL compatibility**: BI-generated SQL may not run because operations such as joins and COUNT(*) aren't defined over Layer 3 objects.
- **Semantic compatibility**: BI tools make assumptions about table-like behavior (e.g. fixed dimension domains) when optimizing queries or implementing features like LoD calculations, Top N filters, and relationships. Those assumptions may not hold for Layer 3 objects, potentially producing incorrect results.
For example, [these Tableau experiments](https://docs.google.com/document/d/1uKc3x9NlvV9O9UPdvlnCTDxsc-XWsQrxb0ylG45H-IQ/edit?tab=t.22qc6753kxb3#heading=h.780gwm47qlmc) illustrate Tableau implementing complex features on top of Layer 2 without product changes, using its existing support for passthrough aggregates.
BI tools also have their own semantics for things like filter propagation and dimension domains in multi-table analyses. Supporting all of these behaviors through Layer 3 would likely require additional extensions and customization.
I agree that Layer 3's higher-level semantics and validity checks are valuable, especially for clients that want the semantic model to handle joins and query construction. But for BI tools that already implement these features, Layer 2 provides a more natural integration point: they can preserve their existing behavior while reusing measures defined in Ossie datasets.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "jbonofre (via GitHub)" <gi...@apache.org>.
jbonofre commented on PR #452:
URL: https://github.com/apache/ossie/pull/452#issuecomment-6271556083
@christianeu-db let me do a quick review to see if it aligns with the discussion on the dev@ mailing list. I will merge just after 😄
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "justint-db (via GitHub)" <gi...@apache.org>.
justint-db commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250786121
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
+how they are queried.** Fan-out and chasm-trap errors cannot occur when measures are queried
+through this interface. The model's datasets are exposed as SQL relations; consumers query them
+with ordinary SQL, using `MEASURE()` in place of raw aggregates.
+
Review Comment:
Generally no. Layer 3 interfaces tend to be very hard for SQL-based BI tools to work with. The reason is that Layer 3 is not relational. So while the results of individual queries against Layer 3 may look reasonable in isolation (and are often completely usable by a human), they do not compose well together.
Perhaps a typical example is a Top N filter, e.g. "Show me the # of unique customers over time in the top 10 states by total revenue".
SQL requires expressing this question as a join between two subqueries that compute the `# of unique customers by date` and `total revenue by state` separately. Layer 3 does not guarantee that the set of states considered by one subquery align with the set of states considered by the other, so the join result can be incorrect. It could return no states, even when there are 10 valid states to return.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "justint-db (via GitHub)" <gi...@apache.org>.
justint-db commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250786121
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
+how they are queried.** Fan-out and chasm-trap errors cannot occur when measures are queried
+through this interface. The model's datasets are exposed as SQL relations; consumers query them
+with ordinary SQL, using `MEASURE()` in place of raw aggregates.
+
Review Comment:
Generally no. Layer 3 interfaces tend to be very hard for SQL-based BI tools to work with. The reason is that Layer 3 is not relational. So while the results of individual queries against Layer 3 may look reasonable in isolation (and are often completely usable by a human), they do not compose well together.
Perhaps a typical example is a Top N filter, e.g. "Show me the # of unique customers over time in the top 10 states by total revenue".
SQL requires expressing this question as a join between two subqueries that compute the `# of unique customers by date` and `total revenue by state` separately. Layer 3 decides which joins to use for those two subqueries independently. If it picks different joins or join types (which is common), Layer 3 does not guarantee that the set of states considered by one subquery align with the set of states considered by the other, so the join of the two subqueries can be incorrect. It could, for example, return no states, even when there are 10 valid states to return.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "vigneshc (via GitHub)" <gi...@apache.org>.
vigneshc commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250499639
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
Review Comment:
Layer 3 resolves which source tables to join.
With that, would joining explicitly to other models be a supported scenario in Layer 2? If it is, shouldn't we define the expected semantics for the cases like below
- A physical table that is part of a model, is joined directly.
- Two separate models are explicitly joined.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "vigneshc (via GitHub)" <gi...@apache.org>.
vigneshc commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250507680
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
+how they are queried.** Fan-out and chasm-trap errors cannot occur when measures are queried
+through this interface. The model's datasets are exposed as SQL relations; consumers query them
+with ordinary SQL, using `MEASURE()` in place of raw aggregates.
+
Review Comment:
Shouldn't the BI tools go explicitly through Layer 3? Isn't that simpler, and wouldn't that result in avoiding potentially incorrect queries?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "christianeu-db (via GitHub)" <gi...@apache.org>.
christianeu-db commented on code in PR #452:
URL: https://github.com/apache/ossie/pull/452#discussion_r4250645281
##########
core-spec/spec_layers.md:
##########
@@ -0,0 +1,173 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Ossie Specification Layers
+
+**Status:** Informational / Architecture Overview (Draft).
+**Contributors:** Justin Talbot, Will Pugh, Chris Eubank.
+
+---
+
+## Overview
+
+This document is an informational architecture overview. It describes how the Ossie
+specifications fit together and links to the specification for each layer. It does not
+define normative requirements itself; those are in each layer's specification.
+
+Ossie is organized into four specification layers, each addressing a distinct concern:
+
+| Layer | Name | Role |
+|-------|------|------|
+| 1 | Model Definition | Model definition: the Ossie model format and the expression language used within it |
+| 2 | Relational Query Interface | Query interface: SQL-native, grain-safe measure evaluation, full SQL invariants |
+| 3 | Wide Table Query Interface | Query interface: declarative flat-object queries, heuristic join resolution |
+| 4 | Ontology | Ontology workstream: higher-order semantic and knowledge-graph concepts |
+
+Layer 1 defines what an Ossie model *is*—the model format and the expression language authors
+use to write it. Layers 2 and 3 are query interfaces that sit on top of a deployed model;
+they differ in how much SQL knowledge they require from the consumer. Layer 4 is a separate
+workstream covering ontological concepts that SQL does not naturally express.
+
+Each layer can be adopted independently. Layers 2 and 3 compose: the meaning of a wide-table
+query (Layer 3) is defined by an equivalent SQL measures query (Layer 2), so correctness
+guarantees flow through.
+
+---
+
+## The Layers
+
+### Layer 1 — Model Definition
+
+Layer 1 defines what an Ossie model *is*. It covers two related specifications:
+
+**Model format** ([`spec.md`](spec.md)): the structure of an Ossie model file—datasets,
+relationships, fields, and metrics. This is the interchange format: the common schema that
+allows semantic model definitions to be moved between tools.
+
+**Expression language** ([`expression_language.md`](expression_language.md)): the portable SQL
+expression subset used to write measure definitions, calculated fields, and filter predicates
+within a model file. Layer 1 establishes the guarantee: **expressions in an Ossie model
+evaluate identically on any conforming engine.** A model authored once can be deployed anywhere
+without rewriting its expressions.
+
+Together these define the authoring layer of Ossie. Layer 1 is a model *definition* concern,
+not a query concern. It does not prescribe the query language a consumer uses against a deployed
+model—that is a per-layer decision for Layers 2 and 3.
+
+### Layer 2 — Relational Query Interface
+
+Layer 2 is the SQL-native query interface for Ossie models. Its query language is the Layer 1
+expression language extended with the relational constructs of SQL: joins, group-by, filters,
+CTEs, ordering, etc. To this it adds one extension, `MEASURE()`, which evaluates a named
+measure at its declared grain.
+
+Layer 2 establishes the guarantee: **measures are evaluated without duplication regardless of
Review Comment:
Layer 2 is designed to sit below the Layer 3 multi-table interface. Layer 2 objects behave like tables with measures, while Layer 3 provides a higher-level interface over a graph of datasets. Layer 3 has additional semantics (e.g., dimension domains can depend on which measures are selected) that make interoperability with SQL joins more involved.
To your questions:
- Joining a physical table: Supported. A regular SQL table can be joined with a Layer 2 dataset, just as it can with any other table.
- Joining two models: Layer 2 supports explicitly joining datasets from different models. However, joining two Layer 3 model-level query interfaces is outside its scope. Layer 2 operates on datasets and other table-shaped objects, not entire models.
It's reasonable to define how Layer 3 objects, including their graph-aware semantics and dynamic dimension domains, interact with broader SQL. But I'd expect that to be addressed in the Layer 3 proposal rather than Layer 2.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(core-spec): Add Ossie specification layers overview [ossie]
Posted by "kayemkim (via GitHub)" <gi...@apache.org>.
kayemkim commented on PR #452:
URL: https://github.com/apache/ossie/pull/452#issuecomment-6182846223
Read at ada1207 against the Layer 1 spec and the current text of #354. Two notes, neither blocking.
The Layer 1 paragraph bolds "expressions in an Ossie model evaluate identically on any conforming engine". expression_language.md promises less than that: core functions work identically, dialect extensions MAY go beyond the core, and the locale-dependent date tokens are explicitly "not guaranteed identical across engines". Saying that the portable core evaluates identically would match what Layer 1 actually guarantees and keep the overview from reading as stronger than the spec it points to.
Nothing links to spec_layers.md yet. spec.md, docs/index.md and ROADMAP.md all point straight to spec.md and expression_language.md, so a reader who starts from any of them never reaches the overview. One line in the "Specification at a Glance" section of docs/index.md, or at the top of spec.md, would fix that, here or as a follow-up.
The six list threads resolve to the cited subjects and dates, the relative links exist, and AGG() matches #354, which now keeps MEASURE() only as an engine-specific spelling.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org