Expand custom_extensions to be more suitable for application-specific metadata

[cpimhoff]

I think the current definition for custom_extensions is overly prescribed when it doesn’t need to be. The intent of this field seems to be to encode any additional data that isn’t native to the OSI, such that other systems (or a re-comsumption by the original system) may opportunistically read.

custom_extensions:  
  - vendor_name: string  # Must be from vendors enum
    data: string         # JSON string

Currently it fails at this task, since vendor_name is a required enum that is currently very limited to 3 big players and “COMMON” which gives a single namespace for everyone else. This vendor_name approach also gives little room for a single vendor to produce multiple extensions. The data encoding is also encoded as a JSON string for no practical reason.

Particularly as application authors do novel things, this means that either A) application authors will break the specification by encoding things that technically aren’t allowed by the specification format, or B) applications will not be able to use OSI for novel things without first pushing the entirety of their use case through extensive review.

---

I propose a simpler definition for this property:

custom_extensions:
    [extension_id: string]: any

Where extension_id is a vendor-specific prefixed bundle identifier.

This allows each vendor to contribute and read against this field without any constraints, while maintaining a decent pattern to not step on one another:

custom_extensions:
    "dbt.meta": { materialized: "table" }
    "hex.import.ownerEmail": "alee@hex.tech"

[anentropic]

Similar thoughts here

The design seems bad, or perhaps it's deliberately intended to discourage 3rd party usage

Why the vendor enums - no one else gets to be a vendor? Same with dialects. Why custom extensions have a value as a JSON string embedded in the YAML doc?

Extension ids could be URIs, domain name would prevent collisions

Why even group things under custom_extensions, really we just want app namespaces.