Depends on: -
RFCs: RFC-016
Abstract
This spec defines the ODF schema format used to describe the logical structure of independently of how it is physically encoded in files (e.g. Parquet, Avro, CSV) or in memory (e.g. Arrow). It defines the set of supported logical types, the mechanism for attaching custom attributes to schemas and fields, and the rules for converting between ODF and Apache Arrow schemas.Logical Types vs. Encoding
ODF schema describes logical types of data - the semantics and value boundaries of a type and how it can be operated on. It deliberately does not capture the encoding (physical layout) of data such as compression, dictionary encoding, offset widths, or view-based representations. This separation ensures that:- Logical types remain stable across different file formats, data chunks, and engines
- Encoding strategies (compression, dictionary usage, encoding hints) can evolve independently, both at the file level and in memory
- Producers and consumers can negotiate encoding at runtime while relying on a consistent logical schema contract
Schema Format
A (DataSchema) consists of:
fields- an ordered list of top-level fields (columns)extra- optional extra attributes that apply to the schema as a whole
DataField) consists of:
name- name of the fieldtype- logical type of the fieldextra- optional extra attributes that apply to the field
Nullability
Fields are non-nullable by default. Nullability is expressed explicitly via the specialOption type that wraps the type of the value (unlike Arrow, where nullability is a property of a field). This applies recursively to nested types, e.g. struct fields and list items.
Logical Types
Time units are:
Second, Millisecond, Microsecond, Nanosecond.
See reference for the full definition.
Short Form
Types that don’t require any parameters can be specified as a plain string instead of an object with akind field. The following two definitions are equivalent:
Extra Attributes
Extra attributes is a key-value map that allows attaching custom information to schemas and fields. Keys must be in the format<domain>/<attribute-name> (e.g. kamu.dev/archetype). The domain prefix is used to disambiguate attributes and avoid name collisions between different extensions.
Values can be a string or any JSON value, including nested objects.
Extra attributes are represented natively in YAML and JSON, and as a JSON-encoded string in FlatBuffers.
Well-known Attributes
Conversion to and from Arrow
Implementations should be able to convert between ODF and Arrow schemas back and forth without information loss. Since ODF schema captures only logical types, Arrow encoding details are preserved using encoding hints in extra attributes: Arrow type:LargeUtf8
Utf8View (analogously for BinaryView, ListView, LargeListView)
Date64 (millisecond-based representation)
Decimal128 (analogously for Decimal256)