IPLD Schemas Feature Summary

Constructs for Describing Common Data Forms

IPLD Schemas present basics that are well-understood in many programming ecosystems (sum types, product types, some specific recursive types):

Typed maps

{Foo:Bar}

Typed lists

[Foo]

Typedef'd primitives

type Foo int

Structs

type FooBar struct {
f Foo
b Bar
}

Discriminated unions (several styles matching those commonly found in the wild)

type union FooOrBar {
Foo "f"
Bar "b"
} representation keyed

Enumerations

type FBB enum {
| "Foo"
| "Bar"
| "Baz"
}

A simple syntax for 'maybe' data elements

type Foo struct {
f nullable Bar
}

type Bar [nullable Foo]

A clear syntax for non-required fields

type Foo struct {
f optional Bar
}

Hooks for transparently transforming data with programmatic logic

advanced ROT13
type EncryptedString string representation advanced ROT13

Mapped to the Data Model

All of this maps over the IPLD Data Model:

Some things can go even further than the basic representations. "Advanced data layouts" define types that can act as already-familiar data kinds such as Maps or Lists or Bytes (byte arrays), while using a fully pluggable system to transform the content into other forms for representation. A common use of such a feature is splitting data into fully separate chunks for storage, allowing:

All the same tools that work over the IPLD Data Model also work atop Schemas:

All of the generic IPLD algorithms can work over a Schema node in exactly the same way as over nodes in the plain Data Model. This allows novel behaviors such as pathing through a Struct by field names even if the Struct representation is a list.