Repository navigation
docs(extensions): drop vendor-specific data examples from vendors.md & point to converters repo - #666
Conversation
The per-vendor `data` payload examples in vendors.md implied a structure that Ossie does not define. Ossie carries `custom_extensions[].data` as an opaque string, so the authoritative per-vendor extension details belong with the converters, not the core registry. Remove the Examples section and point readers to the apache/ossie-converters repository for the precise extensions a given vendor emits and consumes. Co-authored-by: Isaac <no-reply@databricks.com>
addc163 to
541caa0
Compare
christianeu-db
changed the title
kayemkim
left a comment
kayemkim
left a comment
There was a problem hiding this comment.
One sentence still points at what this removes: core-spec/spec.md line 598 says "For vendor-specific extension examples and the known-vendor catalog, see extensions/vendors.md", and after this lands the file has the catalog but no examples. Dropping "vendor-specific extension examples and" there would close it. Nothing else reads those payloads, the vendor pin test parses the table line by line and passes on current main with this merged, and the converters README does carry the data convention the new pointer refers to.
The spec pointed readers to extensions/vendors.md for "vendor-specific extension examples and the known-vendor catalog". The companion change removes the examples from that file, so the reference now points only at the known-vendor catalog. Co-authored-by: Isaac <no-reply@databricks.com>
|
@kayemkim Good catch. Dropped "vendor-specific extension examples and" from core-spec/spec.md, so the sentence now reads "For the known-vendor catalog, see extensions/vendors.md" - which matches the file's contents after this change |
Summary
extensions/vendors.mdcarried a per-vendor Examples section that showedsample
custom_extensions[].datapayloads (Snowflake, Salesforce, DBT,Databricks). Ossie treats
dataas an opaque string that it carries butdoes not interpret, so those examples implied a payload structure the core
spec does not actually define.
Additionally, some of these payloads are from before the converters were even
written, so may not even be valid.
This PR removes the Examples section and adds a line pointing readers to
the apache/ossie-converters
repository, where the precise extensions a given vendor emits and consumes
are defined. The Known vendors registry is unchanged.
Related Issues
Follows #617 - which removed vendors from core spec
Checklist
Documentation
docs/is updated to reflect any user-facing changesAI disclosure
Per the ASF Generative Tooling Guidance, this contribution was prepared with AI assistance. I have reviewed and verified every change.