[johndacosta]

Summary

Adds table sources with ordered, exact identifier parts and optional {name, level} labels. Plain parts imply no level, and the number of parts is unrestricted. Consumers supply missing leading context or reject clearly rather than flattening names.

Existing string sources, including queries, remain unchanged. Query objects and per-dialect sources are outside this PR. No breaking change to the released spec; qualification existed only in unreleased branch work.

Discussed on dev@: https://lists.apache.org/thread/zkxh5k42l39bg0clj6mff2mb1h12ml5o
Related to #298 and #698.

Verification

At commit 632b63b:

• 59 validation unittests, 639 validation tests, and 316 Python tests pass.
• Type generation, seven example checks, and the license check pass.
• Codex independently reran all 1,014 tests. Grok reviewed the final diff and test evidence in read-only mode.

Downstream compatibility

apache/ossie-converters still requires string sources and assumes positional identifier parts. Table objects and arbitrary part counts need a separate converter change; a matching issue has not yet been filed. Existing three-part strings remain supported.

Checklist

• Spec, schema, Python types, validation, examples and documentation updated.
• Existing flights source names preserved.
• Validation CI includes the new example.
• No ontology change needed; it does not define Dataset.source.
• Tests and license checks pass; no new dependency or vendored source added.
• Matching converter issue or PR remains to be filed.

Prepared with Grok Bot. Feature and correction commits include Generated-by: Grok Bot. Licensed under Apache-2.0.

[kayemkim]

Two sentences disagree on the same case: under Source a consumer MAY reject a source whose identifier it cannot resolve, under Resolving a Table it MUST reject it with a diagnostic. The MUST is what the thread settled on, so the first bullet could defer to it.

The example and the Source snippet carry the connection as custom_extensions with data as a JSON string. #522 renames the key to nonportable_extensions and makes data an object, and on the merged tree examples/dataset_sources.yaml fails the new CI step with 'custom_extensions' was unexpected. Whichever lands second takes the rename and data: {connection: warehouse_prod}.

#698 adds a validate_dataset_sources of its own that parses a string source starting with SELECT or WITH, so the two need merging by hand, and a query source would then get this [Source] warning next to #698's parse result. The existing examples all use shorthand and validate exactly as on main, and the new example round-trips through the SDK unchanged.

[xsko]

We are a producer that needs both of the shapes this PR allows, so here
is what it looks like on our side.

ElastiCORE (XSOLCORP KOREA) generates a Spring application and its
tables from a model the user writes, and it writes the Ossie file from
the same model.

When the model names a schema, we know the name and we know it is a
schema, because the same value goes into the generated JPA
@Table(schema=...) and into the DDL. When the model names no schema,
we have the table name and nothing above it. Neither case is a guess we
can fill in later.

So one producer writes both:

identifier:
  - {name: acct, level: schema}
  - {name: customer, level: table}

identifier: [ps_category]

We changed our exporter yesterday so that it stops dropping the schema:
xsko/ElastiCORE#124

For now it writes the dotted string, acct.customer. It is valid in the
current release, and under this PR it splits into the same two parts.
When this is in a release we will write the list form with level.

Our sample project still exports one part only, because that model names
no schema:
https://github.com/xsko/ElastiCORE/blob/main/elasticore-project/elasticore-sample-petstore/src/main/resources/blueprint/semantic_model.yml

On the open checklist item: ossie-converters still assumes positional
parts and no issue is filed. I can file it with both shapes above as
test cases.

(Same producer as the dev@ thread; I sent the mail as Richard Kim.)

[harels]

Hey all, chiming in from the OpenLineage project. It's my first time engaging with the Ossie community :)
Thanks for driving this! I also read through the great discussion on the dev@ thread.

+1 to the list form with optional levels.
One data point in favor: OpenLineage has landed on almost the same shape. Our dataset identity is a namespace (the system/instance, e.g. snowflake://org-account) plus a name, and our HierarchyDatasetFacet carries the name as an ordered list of {type, name} levels, highest first.
So an Ossie identifier could map directly to an OpenLineage dataset name and its hierarchy, which I think can make it easy to link a model's datasets to the lineage of the tables they're built on.

It also matches how we treat the other part of the identifier: like in this PR, we don't treat the system/instance as part of the name.
In OpenLineage it comes from job-level integration, rather than static model.

The proposal of a binding separate from the model seems like the right place for that, and we'd be glad to collaborate on the naming conventions there if it's useful.
Also happy to maintain them in a shared repo if that makes sense?

Looking forward to start the collaboration, didn't necessarily want to take over this PR discussion, but felt like a good place to start? should I be posting this to the mailing list instead?