Expression language Doc#150
Conversation
QMalcolm
left a comment
QMalcolm
left a comment
There was a problem hiding this comment.
Thank you for putting this together ❤️ Still working through it, adding some initial comments as a checkpoint
|
|
||
| ## Overview | ||
|
|
||
| ![][image1] |
There was a problem hiding this comment.
This image isn't rendering on github when I view this markdown file (view page). I'm trying to think how I did this in the past. I believe instead of embedding the encoding at the bottom of the markdown I instead added the photo as a separate file, and then added the relative link to it in the markdown?
|
|
||
| This proposal is only targeted at the Logical Layer. It would be nice if the Ontological layer could re-use the same expression language, but that will be treated as a separate proposal. | ||
|
|
||
| This document defines the SQL expression language subset that OSI-compliant implementations MUST support. The goal is to provide a portable expression language that works across all OSI implementations while allowing vendors to expose richer database-specific functionality through dialect extensions. In particular, it is meant for expressions at the logical layer. This means metrics, fields, filters, etc In the future, expressions such as arbitrary join expressions should also use this expression language. |
There was a problem hiding this comment.
I think in going forward with this decision we should drop database-specific dialects. In my mind OSI/Ossie is meant to to be a portable standard. The OSI/Ossie SQL expression language essentially enforces that. Allowing for dialects inherently breaks that. Maybe the escape hatch of dialects is necessary, but I think it also fundamentally breaks the contract. However, maybe the various opinions on dialect are controversial enough that what I'm talking about needs it's own proposal 😅
There was a problem hiding this comment.
Yeah. I agree with this, but would break it into a separate PR. That may be a more controversial opinion.
My current strategy is to:
- define the expression language
- then make it default
- Try to remove the ability to set dialect at the expression language. Basically only allow it at the root. I had a PR a while ago that I proposed this: POC for a switch to having a single dialect for the whole file.
- Reduce down to only allowing the OSI expression language
I would hope 1 & 2 are not controversial. I'm interested in whether 3 is
Replace inline base64 PNG in expression_language.md with a relative file reference to core-spec/img/osi_layers.png, which renders correctly both locally and in the GitHub UI. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
2 participants
This is an MD file version of OSI Proposal: Expression Language which the Expression Language sub-group put together.
It is a sub-set of ANSI SQL with clarifications on places that ANSII does not define, so that OSI documents are portable. The dialect name is OSI_SQL_2026.