Schema System
Overview
The NYRA framework uses a schema system to define and validate data structures—known as NYRA Values—within the NYRA runtime. These schemas describe properties for extensions and the messages exchanged between them, ensuring data consistency, type safety, and proper data handling across different components in the NYRA framework.
Example of a NYRA Framework Schema
{
"api": {
"property": {
"exampleInt8": {
"type": "int8"
},
"exampleString": {
"type": "string"
}
},
"cmd_in": [
{
"name": "cmd_1",
"property": {
"foo": {
"type": "int8"
},
"bar": {
"type": "string"
}
},
"result": {
"property": {
"x": {
"type": "int8"
},
"y": {
"type": "string"
}
}
}
}
],
"cmd_out": [],
"data_in": [],
"data_out": [],
"video_frame_in": [],
"video_frame_out": [],
"audio_frame_in": [],
"audio_frame_out": []
}
}Design Principles of the NYRA Framework Schema System
Object Principle
Every field’s schema must be defined as an object. This ensures a structured, consistent format for all schema definitions.
Correct format:
{
"foo": {
"type": "int8"
}
}Incorrect format:
{
"foo": "int8"
}Metadata-Only Principle
Schemas define only metadata, not actual data values. This separation ensures the schema stays a template for validation, avoiding any mixture of data contents.
Conflict Prevention Principle
Within any JSON level containing a NYRA schema, all fields should be user-defined except reserved fields like "_nyra". This prevents overlap between user fields and system-defined fields.
Example with user-defined fields:
{
"foo": "int8",
"bar": "string"
}Example with reserved "_nyra" field:
{
"_nyra": {
"xxx": {}
},
"foo": "int8",
"bar": "string"
}Defining Types in a NYRA Schema
Primitive Types
The NYRA framework supports these primitive types:
int8, int16, int32, int64
uint8, uint16, uint32, uint64
float32, float64
string
bool
buf
ptr
Example:
{
"foo": {
"type": "string"
}
}Another example:
{
"foo": {
"type": "int8"
}
}Complex Types
Object
{
"foo": {
"type": "object",
"properties": {
"foo": {
"type": "int8"
},
"bar": {
"type": "string"
}
}
}
}Array
{
"foo": {
"type": "array",
"items": {
"type": "string"
}
}
}Defining the NYRA Schema for Properties
Example Property Schema
{
"exampleInt8": 10,
"exampleString": "This is a test string.",
"exampleArray": [0, 7],
"exampleObject": {
"foo": 100,
"bar": "fine"
}
}Corresponding NYRA Schema
{
"api": {
"property": {
"exampleInt8": {
"type": "int8"
},
"exampleString": {
"type": "string"
},
"exampleArray": {
"type": "array",
"items": {
"type": "int64"
}
},
"exampleObject": {
"type": "object",
"properties": {
"foo": {
"type": "int32"
},
"bar": {
"type": "string"
}
}
}
}
}
}Defining the NYRA Schema for Commands
Input Command Example
{
"_nyra": {
"name": "cmd_foo",
"seq_id": "123",
"dest": [
{
"app": "msgpack://127.0.0.1:8001/",
"graph": "default",
"extension_group": "group_a",
"extension": "extension_b"
}
]
},
"foo": 3,
"bar": "hello world"
}Corresponding NYRA Schema
{
"api": {
"cmd_in": [
{
"name": "cmd_foo",
"_nyra": {
"name": {
"type": "string"
},
"seq_id": {
"type": "string"
},
"dest": {
"type": "array",
"items": {
"type": "object",
"properties": {
"app": {
"type": "string"
},
"graph": {
"type": "string"
},
"extension_group": {
"type": "string"
},
"extension": {
"type": "string"
}
}
}
}
},
"property": {
"foo": {
"type": "int8"
},
"bar": {
"type": "string"
}
}
}
]
}
}Note: To avoid redundancy, the NYRA framework lets you skip defining the
"_nyra"field in your schema, since the runtime reserves it.
Defining Command Results
Command results follow the same pattern but describe the expected response:
{
"api": {
"cmd_in": [
{
"name": "cmd_foo",
"property": {
"foo": {
"type": "int8"
},
"bar": {
"type": "string"
}
},
"result": {
"property": {
"aaa": {
"type": "int8"
},
"bbb": {
"type": "string"
}
}
}
}
]
}
}Defining the NYRA Schema for Data, Video Frames, and Audio Frames
Use a similar approach to commands but omit the result field. Data, video frames, and audio frames typically don’t require response payloads.
Manifest Schema Overview
The manifest.json file holds the schema for an extension’s properties and messages, ensuring proper configuration and communication structures.
Example manifest.json
manifest.json{
"type": "extension",
"name": "A",
"version": "1.0.0",
"dependencies": [],
"api": {
"property": {
"app_id": {
"type": "string"
},
"channel": {
"type": "string"
},
"log": {
"type": "object",
"properties": {
"level": {
"type": "uint8"
},
"redirect_stdout": {
"type": "bool"
},
"file": {
"type": "string"
}
}
}
},
"cmd_in": [],
"cmd_out": [],
"data_in": [],
"data_out": [],
"video_frame_in": [],
"video_frame_out": [],
"audio_frame_in": [],
"audio_frame_out": []
}
}Conclusion
The NYRA framework’s schema system provides a robust, structured method to define and validate data structures. By adhering to principles of object formatting, metadata separation, and conflict prevention, developers can maintain consistency and safety for extensions and their interactions in the NYRA runtime.
Last updated