Add THOUGHTSPOT to the Dialect enum and SKIP_SQL_VALIDATION

[djwaldo]

Summary

Registers THOUGHTSPOT as an expression-language dialect, mirroring exactly what MDX, TABLEAU and MAQL already do.

ThoughtSpot's formula language is not SQL. It has its own syntax and its own column-reference form:

concat ( [ORDERS::Region] , ' - ' , [ORDERS::Segment] )
if ( [Revenue] > 0 ) then 'positive' else 'zero or below'

Two things follow. Dialect is a closed enum, so a THOUGHTSPOT entry fails schema validation outright. And validate_sql falls through to a default-dialect sqlglot parse for anything not in SKIP_SQL_VALIDATION, so such an expression would raise a parse error rather than being left alone — which is precisely why MDX, TABLEAU and MAQL are in that set.

Evidence

A semantic model carrying ThoughtSpot expressions on both a field and a metric, against validation/validate.py:

Before

Validation FAILED with 2 error(s):
  [Schema] ... fields -> 0 -> expression -> dialects -> 0 -> dialect:
      'THOUGHTSPOT' is not one of ['ANSI_SQL', 'SNOWFLAKE', 'MDX', 'TABLEAU', 'DATABRICKS', 'MAQL', 'BIGQUERY']
  [Schema] ... metrics -> 0 -> expression -> dialects -> 0 -> dialect:
      'THOUGHTSPOT' is not one of [...]

After

Validation PASSED

Existing python/ and validation/ suites: 19 passed.

Impact on existing implementations

None. No behaviour changes for any other dialect — the change is additive to a vocabulary. A consumer that does not know THOUGHTSPOT treats it as it would any dialect it does not implement.

Why five files

The dialect vocabulary is stated in five places, and they have to agree:

File	Change
core-spec/ossie-schema.json	the Dialect enum
core-spec/spec.md	the dialect table
core-spec/spec.yaml	the dialects list
validation/validate.py	DIALECT_MAP entry (None) + SKIP_SQL_VALIDATION
python/src/ossie/models.py	the OssieDialect enum

The last is easy to overlook — without it the JSON schema accepts the dialect while the shared Python models package still rejects it.

The DIALECT_MAP entry is strictly redundant, since SKIP_SQL_VALIDATION short-circuits before the lookup, but MDX/TABLEAU/MAQL are each in both and I have followed that pattern rather than diverge from it.

Possibly relevant beyond this dialect

In discussion #342 on shared filters, part of the argument turns on a parse-based join-path resolution strategy being unworkable for any dialect in SKIP_SQL_VALIDATION. That set currently has three members; this would make it four. Better known while that design is under discussion than after.

Related Issues

Context: #285 and #269 (ThoughtSpot converter). Announced on dev@ossie.apache.org: [DISCUSS] ThoughtSpot converter: scope, licensing, and where it should live, with a dedicated thread for this change.

Per CONTRIBUTING's specification-change process this is opened alongside the dev@ announcement, for the 7-day discussion window and a [VOTE].

Checklist

Specification

• Spec changes are included in core-spec/ and follow the existing structure
• Spec changes have been discussed on the mailing list or in a linked issue
• Breaking changes to the spec are clearly called out in the summary — there are none; the change is additive

Validation

• Validation rules in validation/ are updated
• New validation cases are covered by tests — no existing test references any specific dialect member; happy to add one if reviewers would like

Tests

• All existing tests pass (19 passed)

Compliance

• ASF license headers are present on all new source files — no new files
• No third-party dependencies are added

[jbonofre]

That's ok, but worth to note that some converters will "fail".

For instance in nvidia GSF, _pick_expression finds no ANSI_SQL and silently fails through to return expression[0]["expression"], writing the ThoughtSpot formula into a GSF model as a SQL expression (no warning).
I believe DBT and Honeydew converters will behave the same.

Before this PR, the schema gate rejected such a document. Now it is accepted and produces broken output two layers down. The root cause is that no converter has any machine-readable way to ask "is this dialect SQL?".

Nothing to consider soon.