Change vendor_name from enum to free-form string - #91
Conversation
jbonofre
left a comment
jbonofre
left a comment
There was a problem hiding this comment.
osi-schema.json should be updated on line 20-26 as it still references the array.
It also still mentions Supported vendors for custom extensions (enumeration definition) which is not accurate anymore.
In the spec.md, the custom extensions section (line 359) still show:
custom_extensions:
- vendor_name: string # Must be from vendors enum
which is not accurate with the change.
Also CustomExtension in schema still references $ref: "#/$defs/Vendor". While the Vendordef itself is updated, the overallvendors` top-level property and its description remain inconsistent.
If I understand the intent (relaxing vendors), and it makes to me, I suggest to update the vendors ref across the three files to be consistent.
Can you please do a complete pass to update all enum references ?
|
Thanks for the review! I've addressed the feedback:
All remaining enum references should now be consistent with the change to a free-form string. |
|
@jochenchrist Many thanks ! I'm doing a new pass. |
|
The change makes sense, but would end up being a breaking change. Let's use git tag for versioning and then it would still be nice to have static shareable links for the different versions of the spec via build automation tooling ? @jbonofre what do you think ? |
|
@khush-bhatia I agree. We have I can work on the "CI" to verify and manage the versions. Thoughts ? |
|
@jochenchrist Thanks for this PR. We have done the release work. And now this PR can be merged to main. Do you mind rebasing this PR to the latest main ? |
Allow any vendor or organization to define custom extensions without requiring changes to the core specification. Existing vendor names (COMMON, SNOWFLAKE, SALESFORCE, DBT, DATABRICKS) are preserved as examples. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Update vendors array description in osi-schema.json to reflect non-exhaustive examples instead of enumeration definition - Update spec.md custom extensions schema comment from "Must be from vendors enum" to "Free-form string identifying the vendor" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4aa1c09 to
b1f67b5
Compare
|
Thanks @khush-bhatia! Rebased onto latest main. Resolved the conflict in osi-schema.json / spec.yaml by keeping GOODDATA in the vendor examples list. Ready to merge. |
These top-level enumeration properties were not referenced by any example or downstream consumer. validate.py only reads dialects from each expression's per-dialect entries via the Expression definition. Removing them keeps the root schema focused on version and semantic_model. The Dialect and Vendor $defs are retained for use within Expression and custom extensions. Also drop the now-orphaned Vendors enumeration table from spec.md (vendor_name has been a free-form string since #91; the table was a holdover) and refresh the stale "Must be one of the values from 'vendors' enum above" comments in spec.yaml so they describe vendor_name as a free-form vendor identifier. .... Generated with [Cortex Code](https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code) Co-Authored-By: Cortex Code <noreply@snowflake.com>
These top-level enumeration properties were not referenced by any example or downstream consumer. validate.py only reads dialects from each expression's per-dialect entries via the Expression definition. Removing them keeps the root schema focused on version and semantic_model. The Dialect and Vendor $defs are retained for use within Expression and custom extensions. Also reorganize the Vendors content in spec.md: it no longer fits under the Enumerations section because vendor_name has been a free-form string since #91. Moved it under Custom Extensions as a "Vendor Names" subsection listing well-known examples. Refreshed the stale "Must be one of the values from 'vendors' enum above" comments in spec.yaml so they describe vendor_name as a free-form vendor identifier. .... Generated with [Cortex Code](https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code) Co-Authored-By: Cortex Code <noreply@snowflake.com>
3 participants
Summary
vendor_namein custom extensions from a closed enum to a free-form string, allowing any vendor or organization to define custom extensions without modifying the core specexamplesin the JSON Schema and documented as well-known examples in the specspec.yaml,osi-schema.json, andspec.md🤖 Generated with Claude Code