Hi all,
I would like to ask whether the community has existing plans for, or would welcome, a converter between Apache Ossie and ThoughtSpot Modeling Language (TML).
Why this may be useful
ThoughtSpot represents metadata objects as TML in YAML or JSON. Tables, worksheets, and views can carry columns, formulas, joins, descriptions, and modeling properties that overlap with Ossie datasets, fields, metrics, and relationships. ThoughtSpot also exposes supported TML import/export operations through its API, so static TML is a possible interchange boundary.
Official references:
I searched the open and closed Ossie issues and pull requests and did not find an existing ThoughtSpot or TML converter proposal.
Possible v1 boundary
If the project considers this integration appropriate, I suggest investigating a dependency-free static converter first:
- Read and write static TML YAML or JSON without requiring access to a ThoughtSpot instance.
- Initially limit the supported TML object types to the smallest set that represents semantic modeling, likely tables plus either worksheets or models/views, based on representative exports.
- Map columns and formulas to Ossie fields, reusable aggregate definitions to metrics where unambiguous, and representable joins to Ossie relationships.
- Preserve TML-specific properties in a versioned
THOUGHTSPOT custom extension.
- Report unsupported or ambiguous constructs explicitly.
- Validate generated Ossie documents against
core-spec/osi-schema.json.
- Keep live ThoughtSpot REST API access outside the static converter's runtime scope.
Licensing question
The official thoughtspot_tml Python repository is public but is distributed under a ThoughtSpot Development Tools EULA rather than an OSI-approved open-source license. Its restrictions also require careful review for a format converter. I therefore do not propose depending on, copying from, or distributing that library.
Before implementation, we would need to confirm:
- Whether a converter based only on publicly documented TML and independently written parsing is appropriate for Apache Ossie.
- Whether representative TML fixtures can be contributed under Apache-compatible terms.
- Whether any ASF licensing or legal review is required before proceeding.
Questions for maintainers and contributors
- Is a ThoughtSpot TML converter something the Ossie community would welcome?
- Is anyone already planning or prototyping this integration so that work can be coordinated rather than duplicated?
- If welcome, which TML object types should define the initial semantic scope?
- Should the licensing questions be resolved on the dev mailing list before any code is written?
I have not started implementation because I would like to confirm community interest, existing plans, and the licensing boundary first.
Hi all,
I would like to ask whether the community has existing plans for, or would welcome, a converter between Apache Ossie and ThoughtSpot Modeling Language (TML).
Why this may be useful
ThoughtSpot represents metadata objects as TML in YAML or JSON. Tables, worksheets, and views can carry columns, formulas, joins, descriptions, and modeling properties that overlap with Ossie datasets, fields, metrics, and relationships. ThoughtSpot also exposes supported TML import/export operations through its API, so static TML is a possible interchange boundary.
Official references:
I searched the open and closed Ossie issues and pull requests and did not find an existing ThoughtSpot or TML converter proposal.
Possible v1 boundary
If the project considers this integration appropriate, I suggest investigating a dependency-free static converter first:
THOUGHTSPOTcustom extension.core-spec/osi-schema.json.Licensing question
The official
thoughtspot_tmlPython repository is public but is distributed under a ThoughtSpot Development Tools EULA rather than an OSI-approved open-source license. Its restrictions also require careful review for a format converter. I therefore do not propose depending on, copying from, or distributing that library.Before implementation, we would need to confirm:
Questions for maintainers and contributors
I have not started implementation because I would like to confirm community interest, existing plans, and the licensing boundary first.