feat(python): add ATACCAMA to OssieVendor by rostislavosvald-ataccama · Pull Request #629 · apache/ossie

rostislavosvald-ataccama · 2026-10-22T13:27:00Z

The Ataccama converter in apache/ossie-converters tags its custom extensions with the ATACCAMA vendor name, which needs to be available on OssieVendor before the converter can resolve it against this package.

Summary

This PR adds ATACCAMA among known vendors to the python models and to the specification examples. We are in process of introducing Ataccama convertor, which will expose its custom extension.

Related Issues

None

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

Ontology

N/A

Converters

Spec or ontology changes that affect converters have a matching issue or PR in apache/ossie-converters
Convertor PR will be created soon, however there is a light dependency on the model change.

Validation

N/A

Documentation

N/A: some vendors are mentioned in the docs, but there doesn't seem to be a need to enumerate all

Examples

examples/ are added or updated for any new spec constructs (no new constructs)

Tests

All existing tests pass (pytest / CI green)
New functionality is covered by tests (N/A)

Compliance

ASF license headers are present on all new source files (no new files)
No third-party dependencies are added without PMC/IPMC approval (none added)
If third-party source code is vendored/copied (not just declared as a dependency), NOTICE and/or LICENSE have been updated per ASF policy (no such code)

Copilot

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

No open issues 🎉

What changed in this PR

Registers ATACCAMA as a well-known vendor across the Python model and core specification examples so converters can resolve the vendor name consistently.

Changes:

Added ATACCAMA to the OssieVendor Python enum.
Updated spec example lists (spec.yaml, ossie-schema.json) to include ATACCAMA.
Extended the spec documentation table (spec.md) with ATACCAMA.

File	Description
python/src/ossie/models.py	Adds `ATACCAMA` to the well-known vendor enum used by the Python models.
core-spec/spec.yaml	Updates vendor name examples to include `ATACCAMA`.
core-spec/spec.md	Adds `ATACCAMA` to the documented list of well-known vendor examples.
core-spec/ossie-schema.json	Updates JSON schema vendor examples to include `ATACCAMA`.

_{Review effort: Lite}

christianeu-db

fyi: in #617, we're aiming to remove specific vendor examples from the core spec into an extensions folder. this means that new vendors can register as a known-constant without the usual 7 day DISCUSS period on the mailing list before merging.

If you scope the change to just models.py, I can fold your vendor registration into 617 and get this merged today

github-actions · 2026-10-22T18:46:48Z

Thank you for your first contribution to Apache Ossie (incubating)!

A committer will review your PR. In the meantime, please ensure:

All CI checks pass
ASF license headers are present on new source files
Tests cover new functionality

No ICLA is required to contribute. If you are elected as a committer in the future, you will need an Individual Contributor License Agreement (ICLA) on file with the ASF.

Questions? Ask in the PR comments or join us on Slack.

We appreciate your contribution!

rostislavosvald-ataccama · 2026-10-23T07:36:29Z

fyi: in #617, we're aiming to remove specific vendor examples from the core spec into an extensions folder. this means that new vendors can register as a known-constant without the usual 7 day DISCUSS period on the mailing list before merging.

If you scope the change to just models.py, I can fold your vendor registration into 617 and get this merged today

@christianeu-db Yes that would be great, thank you. Is there something you need from me for this?

christianeu-db · 2026-10-23T07:44:28Z

fyi: in #617, we're aiming to remove specific vendor examples from the core spec into an extensions folder. this means that new vendors can register as a known-constant without the usual 7 day DISCUSS period on the mailing list before merging.
If you scope the change to just models.py, I can fold your vendor registration into 617 and get this merged today

@christianeu-db Yes that would be great, thank you. Is there something you need from me for this?

@rostislavosvald-ataccama just scope the PR down to the models.py change and revert the rest. I'll add | ATACCAMA | Ataccama-specific attributes to the new table in #617

The Ataccama converter in apache/ossie-converters tags its custom extensions with the ATACCAMA vendor name. Adding it to OssieVendor lets the converter use the enum instead of a bare string. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

rostislavosvald-ataccama · 2026-10-23T08:48:57Z

fyi: in #617, we're aiming to remove specific vendor examples from the core spec into an extensions folder. this means that new vendors can register as a known-constant without the usual 7 day DISCUSS period on the mailing list before merging.
If you scope the change to just models.py, I can fold your vendor registration into 617 and get this merged today

@christianeu-db Yes that would be great, thank you. Is there something you need from me for this?

@rostislavosvald-ataccama just scope the PR down to the models.py change and revert the rest. I'll add | ATACCAMA | Ataccama-specific attributes to the new table in #617

@christianeu-db Updated.

Add the ATACCAMA token to the known-vendor table, per apache#629. Co-authored-by: Isaac <no-reply@databricks.com>

Bring in apache#596 (compliance portability fixtures), apache#618 (reject duplicate keys on load), and apache#629 (ATACCAMA vendor) from main. The only conflict was the import block of validation/validate.py, where this branch adds `difflib` plus the `Expression` dataclass/iterator imports and apache#618 adds `importlib.util` for the shared `_loading.py` bootstrap; resolved by keeping the union. apache#618's loader refactor merged cleanly onto the expression-iterator refactor, and apache#629's OssieVendor enum entry is complementary to this branch's vendors.md ATACCAMA row. Verified against validation-ci.yml: duplicate-key tests (59), validation pytest (268), python model tests (266), generator --check in sync, and all five example validations pass. Co-authored-by: Isaac <no-reply@databricks.com>

@abolfazlmadanii

* feat(core-spec): decouple core spec from specific vendor dialects Make the core specification vendor-neutral: - `Dialect` becomes a free-form string (was a closed enum), mirroring the already-free-form `Vendor`; generic schema `examples` replace concrete product names. - Move the known-dialect and known-vendor catalogs out of the normative spec into a new top-level `extensions/` folder (README, dialects.md, vendors.md), framed as a community registry whose listings do not imply endorsement. - Add an optional top-level portable `expression` field (OSSIE_SQL_2026) to the expression object; when both it and an OSSIE_SQL_2026 `dialects` entry are present, the top-level field is authoritative. Demonstrated on `customer_full_name` in examples/tpcds_semantic_model.yaml. - Keep the normative text that non-OSSIE dialects are opaque and declaration-only. Kept in sync: the enum-sync generator no longer emits `dialects` (free-form, like vendors); the Python SDK types `dialect` as a free-form string and gains the optional portable `expression`; the reference validator treats unregistered dialects as opaque (skipped) and validates the portable expression. Converters are otherwise unchanged except where the now-string dialect required a fix (the dbt dialect comparison uses `==`, and the sigma and hex converters no longer call `.value` on a dialect) and where the new portable `expression` is handled: the ontology converter carries it through its model and both conversion directions, and omni's round-trip test documents the portable marker as a normalization (its text survives as the dialect entry). Co-authored-by: Isaac <no-reply@databricks.com> * fix(core-spec): allow portable-only expressions without dialects An Expression required `dialects` on both the JSON Schema and the SDK, so a document carrying only the portable top-level `expression` (OSSIE_SQL_2026) was rejected, contradicting the spec's stated semantics. - Schema: replace `required: [dialects]` with an anyOf requiring at least one of `expression` or `dialects`; `dialects` keeps `minItems: 1` when present. - SDK: make `OssieExpression.dialects` optional and add a model_validator that rejects an expression carrying neither form. - Tests: cover portable-only, dialects-only, both-present, and the empty cases on both the schema and the SDK. - Docs: note the "at least one" rule in spec.md and spec.yaml. Co-authored-by: Isaac <no-reply@databricks.com> * feat(validation): warn on unknown dialects instead of skipping silently An unrecognized dialect is opaque and legitimate under the free-form `Dialect` model, so its SQL cannot be parse-checked. The validator skipped it silently, which also hid typos such as `SNOWFLKE`. `validate_sql` now tallies expressions whose dialect is not in `DIALECT_MAP` and emits one nonfatal `ValidationWarning` per distinct unknown dialect, with the count of affected expressions. Validation still passes. Known-but-unparseable dialects (MDX, DAX, HOLISTICS_AQL, ...) stay silent, and the per-call `validate_sql_expression` is unchanged. Co-authored-by: Isaac <no-reply@databricks.com> * refactor(core-spec): rename portable expression key to 'sql' The portable top-level key of the Expression object was `expression`, nested under a field/metric's own `expression:` block -- the doubled `expression.expression` Jochen flagged on the thread. Rename it to `sql` so the key reads cleanly and names what it holds: the portable OSSIE_SQL (OSSIE_SQL_2026) form. Scope is the portable key only. The field/metric `expression:` key (which holds the Expression object) and the per-dialect `dialects[].expression` key (already qualified by its `dialect:`) are unchanged. This key was introduced by this same unreleased PR, so the rename carries no migration burden; no released spec ever had `expression.expression`. No back-compat alias -- the old key is rejected (schema additionalProperties:false, SDK extra=forbid). Touches the schema anyOf + property, the SDK model and validator, the validator's portable reads, spec.md/spec.yaml/docs prose and examples, the tpcds portable example, and the mirrored tests. Co-authored-by: Isaac <no-reply@databricks.com> * fix(validation): check a dataset-scoped metric's portable sql A dataset-scoped metric may be written with only the portable `sql` form (no dialects). Such a metric escaped both checks: `validate_sql` only walked its `dialects`, so the portable form was never parsed; and `validate_metric_scoping` likewise only walked `dialects`, so the single-namespace scoping rules (no qualified references, declared fields only) were never applied to it. Both now handle the portable `sql` exactly like a dialect expression: it is parsed as OSSIE_SQL_2026 and scope-checked. A portable-only dataset-scoped metric with a cross-dataset reference or an undeclared field is now reported, as a dialect form already was. Adds four tests covering the portable form: a declared single-part field passes, a cross-dataset reference and an undeclared field are rejected, and an invalid portable expression is reported. Co-authored-by: Isaac <no-reply@databricks.com> * refactor(validation): walk expressions through one iterator `validate_sql` and `validate_metric_scoping` each walked the document to find every expression. Introduce `iter_expressions`, the single traversal both consume, yielding an `Expression` record per portable `sql` form and per dialect expression, keyed by `kind` (field / dataset_metric / model_metric). Also folded in while here: - Split the overloaded DIALECT_MAP into SQLGLOT_DIALECTS (parseable, mapped to the sqlglot dialect) and NON_SQL_DIALECTS (carried but not parsed); one guard in _parse_sql_expression indexes SQLGLOT_DIALECTS. - Name the PORTABLE_DIALECT constant; drop the `.get("dialect", "ANSI_SQL")` fallback, since the schema requires `dialect`. - A dialect this validator cannot parse is reported as a nonfatal warning that its expressions were not syntax-checked; it may be a legitimate entry from extensions/dialects.md, not a mistake. - Honor the spec's precedence rule: a top-level `sql` outranks an OSSIE_SQL_2026 dialect entry, so that entry is non-authoritative. It is not scope-checked, and an invalid one warns instead of failing the document, since a client may still read it. - Spec/docs wording: write OSSIE_SQL_2026 directly (no parenthetical), "Any string is accepted", drop "Optional:" from the portable-form comments, describe `data` as an opaque string (not JSON), and give the glossary Dialect entry only ANSI_SQL as an example. - models.py: optional `dialects` comment and the "convenience set, not a closed one" phrasing removed; docstrings state any string is accepted. - Tests track the split, assert exact scope messages, cover the precedence behavior, and compare dialects by value. Co-authored-by: Isaac <no-reply@databricks.com> * fix(validation): tighten sql/dialect handling per PR #617 review Addresses review feedback on the decouple-core-spec PR (#617): - Require non-empty expression and identity strings: add minLength 1 to `sql`, `dialect`, the per-dialect `expression`, and `vendor_name` in both the schema and the SDK, so an empty value is rejected there rather than slipping through -- an empty `sql`/`expression` reached the SQL validator, an empty `dialect` produced an "is not supported" warning, and an empty `vendor_name` was unchecked. Suggested by @abolfazlmadanii. - Warn when a non-authoritative OSSIE_SQL_2026 dialect entry drifts from the authoritative top-level `sql`: a differing or invalid entry is dead text a client might still read, so report it as a nonfatal warning; an identical one stays silent. - Suggest the closest known dialect on an unsupported one (difflib, cutoff 0.8), so `SNOWFLKE` says "Did you mean 'SNOWFLAKE'?" without flagging a genuinely new dialect. - extensions/README.md: note that dialect and vendor tokens are matched exactly and are case-sensitive, so `snowflake` is distinct from `SNOWFLAKE`. - Describe custom-extension `data` as an opaque string, not a JSON string, in the schema and SDK, matching the spec/docs wording. Co-authored-by: Isaac <no-reply@databricks.com> * docs(extensions): register ATACCAMA in the vendor catalog Add the ATACCAMA token to the known-vendor table, per #629. Co-authored-by: Isaac <no-reply@databricks.com> * fix(ci): point #630's precedence tests at SQLGLOT_DIALECTS #630 added OSSIE_SQL_2026 precedence tests whose helper parses through `DIALECT_MAP["OSSIE_SQL_2026"]`. This branch split that map into `SQLGLOT_DIALECTS` (parseable) and `NON_SQL_DIALECTS`, so the merged-in helper hit `AttributeError: module 'ossie_validate' has no attribute 'DIALECT_MAP'`. Point it at `SQLGLOT_DIALECTS[PORTABLE_DIALECT]`, the same None (sqlglot default) entry, so the three tests pass unchanged. Co-authored-by: Isaac <no-reply@databricks.com> --------- Co-authored-by: Isaac <no-reply@databricks.com>

apache/ossie#629 added the enum member, and the ossie submodule is now pinned past it, so the stand-in string constant goes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Copilot AI balanced review requested due to automatic review settings October 22, 2026 13:27

Copilot AI reviewed Oct 22, 2026

View reviewed changes

christianeu-db reviewed Oct 22, 2026

View reviewed changes

Copilot stopped reviewing on behalf of rostislavosvald-ataccama due to an error October 22, 2026 18:38
The job was not acquired by a runner even after multiple attempts.

github-actions Bot added the spec label Oct 22, 2026

rostislavosvald-ataccama force-pushed the feat/ataccama-vendor branch from e5d22fb to 0c46e79 Compare October 23, 2026 08:17

rostislavosvald-ataccama changed the title ~~feat(core): register ATACCAMA as a well-known vendor~~ feat(python): add ATACCAMA to OssieVendor Oct 23, 2026

christianeu-db approved these changes Oct 23, 2026

View reviewed changes

christianeu-db merged commit d85e9e1 into apache:main Oct 23, 2026
1 check passed

christianeu-db added a commit to christianeu-db/ossie that referenced this pull request Oct 23, 2026

docs(extensions): register ATACCAMA in the vendor catalog

43d3e91

Add the ATACCAMA token to the known-vendor table, per apache#629. Co-authored-by: Isaac <no-reply@databricks.com>

github-actions Bot removed the spec label Oct 23, 2026

Navigation Menu

Repository navigation

feat(python): add ATACCAMA to OssieVendor - #629

feat(python): add ATACCAMA to OssieVendor #629
christianeu-db merged 1 commit into
apache:mainfrom
rostislavosvald-ataccama:feat/ataccama-vendor

rostislavosvald-ataccama commented Oct 22, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

christianeu-db left a comment

Uh oh!

github-actions Bot commented Oct 22, 2026

Uh oh!

rostislavosvald-ataccama commented Oct 23, 2026

Uh oh!

christianeu-db commented Oct 23, 2026

Uh oh!

rostislavosvald-ataccama commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

rostislavosvald-ataccama commented Oct 22, 2026

Summary

Related Issues

Checklist

Specification

Ontology

Converters

Validation

Documentation

Examples

Tests

Compliance

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

Uh oh!

christianeu-db left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 22, 2026

Uh oh!

rostislavosvald-ataccama commented Oct 23, 2026

Uh oh!

christianeu-db commented Oct 23, 2026

Uh oh!

rostislavosvald-ataccama commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants