Use this issue to track InQL RFC 040, proposed in PR #60 at docs/rfcs/040_interoperability_semantic_profiles.md.
Area
- Specification (RFCs)
- Documentation
Summary
RFC 040 defines interoperability semantic profiles for recording target, client, backend, version, configuration, catalog/schema, transformation-project, and interchange context around compatibility evidence.
Motivation
Compatibility is not just a yes/no property. Engine behavior, protocol version, adapter configuration, catalog metadata, transformation project assumptions, and client expectations all affect what a plan means and whether a backend or downstream project can execute or represent it faithfully.
Proposal sketch
- Define semantic profile records and dimensions.
- Capture requested, assumed, and observed profile contexts.
- Include profiles for SQL dialects, execution engines, adapter bindings, catalog/schema systems, transformation projects, interchange consumers, and conformance baselines.
- Use representative profile families such as Oracle, PostgreSQL, SQL Server, MySQL, Athena, Presto, Trino, Spark, Snowflake, BigQuery, Redshift, Databricks, Glue Data Catalog, Hive Metastore, dbt, Airflow, MWAA, Dagster, Prefect, OpenLineage, DataHub, OpenMetadata, and Great Expectations.
- Link profiles to adapter coverage, plan bundles, observations, plan diffs, and evidence exchange bridges.
- Avoid treating Substrait, DataFusion, a transformation framework, or a single external engine as the whole profile model.
Alternatives considered
- Use adapter feature flags only.
- Treat Substrait as the only semantic profile.
- Make one engine the normative compatibility target.
- Rely only on conformance tests with no profile evidence.
- Leave profiles to downstream integrations.
Impact / compatibility
This is additive. Profiles should clarify compatibility expectations without changing core query semantics.
Implementation notes (optional)
Review PR #60 for the draft. This work should make compatibility context explicit instead of implicit in adapter names, backend versions, catalog assumptions, or project artifact formats.
Checklist
Use this issue to track InQL RFC 040, proposed in PR #60 at
docs/rfcs/040_interoperability_semantic_profiles.md.Area
Summary
RFC 040 defines interoperability semantic profiles for recording target, client, backend, version, configuration, catalog/schema, transformation-project, and interchange context around compatibility evidence.
Motivation
Compatibility is not just a yes/no property. Engine behavior, protocol version, adapter configuration, catalog metadata, transformation project assumptions, and client expectations all affect what a plan means and whether a backend or downstream project can execute or represent it faithfully.
Proposal sketch
Alternatives considered
Impact / compatibility
This is additive. Profiles should clarify compatibility expectations without changing core query semantics.
Implementation notes (optional)
Review PR #60 for the draft. This work should make compatibility context explicit instead of implicit in adapter names, backend versions, catalog assumptions, or project artifact formats.
Checklist