Hosted onhoraciohdev.dev.hyper.mediavia theHypermedia Protocol

Flexible Schema Mentality

On one extreme, schemas are a waterfall top-down

On the other extreme, content is what it is, and the schema is implied based on what is literally there.

In the middle, you may also have data that defines its own schema. But there is no enforcement that it matches the parent schema above, or the literal data below.

This is especially apparent during schema migrations, and concurrency race conditions. It is possible for data to be in a partially-migrated state.

Modes of Schema

    No Schema - Raw Data that must be read and edited

    Self-Defined Schema - A resource/doc or a blob will self-declare a schema

    Define Schema for children and/or grandchildren

Its possible that a schema (or parent schema) conflicts with reality, this is not great but we must handle it elegantly. In some cases, we should allow the conflict.

Should schemas be editable, and if so, how? Or, is it okay that they are immutable? When editing a schema, do we need to handle concurrency and CRDTs, or is that a liability?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime