Hi team,
I’m very interested in this domain and excited to contribute.
I noticed what appears to be an incomplete schema filename migration following the project’s rename from OSI to Apache Ossie.
The validator currently expects:
core-spec/ossie-schema.json
However, the repository currently contains:
core-spec/osi-schema.json
As a result, running:
python3 validation/validate.py examples/tpcds_semantic_model.yaml
fails with:
Error: Schema not found: .../core-spec/ossie-schema.json
I searched the repository and found that osi-schema.json is still referenced by the root README, documentation, roadmap, TPC-DS example, ontology files, and the Salesforce converter. The schema’s own $id also still uses osi-schema.json.
Since the project has been renamed to Apache Ossie, would the preferred resolution be to:
- Keep
osi-schema.json as the canonical filename and update the validator; or
- Complete the migration to
ossie-schema.json by renaming the schema and updating all repository references?
I think option 2 would provide better long-term naming consistency, although it may require a compatibility plan for existing consumers that reference the old schema URL.
I’d be happy to contribute the complete migration once the intended canonical filename and backward-compatibility approach are confirmed.
Thanks!
Hi team,
I’m very interested in this domain and excited to contribute.
I noticed what appears to be an incomplete schema filename migration following the project’s rename from OSI to Apache Ossie.
The validator currently expects:
However, the repository currently contains:
As a result, running:
fails with:
I searched the repository and found that
osi-schema.jsonis still referenced by the root README, documentation, roadmap, TPC-DS example, ontology files, and the Salesforce converter. The schema’s own$idalso still usesosi-schema.json.Since the project has been renamed to Apache Ossie, would the preferred resolution be to:
osi-schema.jsonas the canonical filename and update the validator; orossie-schema.jsonby renaming the schema and updating all repository references?I think option 2 would provide better long-term naming consistency, although it may require a compatibility plan for existing consumers that reference the old schema URL.
I’d be happy to contribute the complete migration once the intended canonical filename and backward-compatibility approach are confirmed.
Thanks!