Add `plugin.schema`?

[samuelstroschein]

Context

Add plugin.schema: JSONSchema for runtime reflection of the types and runtime validation (ensuring that the history is not broken?

Pros

• switching from one plugin to another that uses the same schema becomes possible
• lix can validate the snapshots, ensuring that the history always obeys to the schema
• lix can use the schema information for diffing only snapshots (instead of entire files)

[samuelstroschein]

If https://github.com/opral/lix-sdk/issues/42 is accepted, the schema would be payloadSchema without the nesting of types.

Here is an example payload schema for the inlang plugin if LIX-109 is accepted.

const plugin = {
  payloadKey: "inlang",
  payloadSchema: {
    snapshot: [bundle, bundleV2, message, variant]
  }
}

[samuelstroschein]

The schema key doesn't seem to be needed. The type can point to schema information.

The current proposal proposes a schema key that points to a schema with multiple types. What if we simply define type as "you point to a type"?

• removes a redundant property (disk space, simpler explainability, etc.)
• de-couples schema definitions from a plugin
  • plugins can share types
  • potential other benefits
• de-couples type information (which can be retrieved from the schema)

id: "change2",
file_id: "mock",
-schema_key: "opral-csv",
-type: "cell"
+schema: "opral-csv-cell",