SchemaInterface

Core Concepts: The Validation Engine

Understanding the determinism behind SchemaInterface's parsing and evaluation model.

Note: This documentation assumes familiarity with JSON Schema Draft 2020-12. If you are migrating from Draft 7, please review the migration guide first.

The Validation Lifecycle

SchemaInterface does not use regular expressions for structural validation. We compile schemas into an intermediate Abstract Syntax Tree (AST) that enforces deterministic state machine transitions. This prevents catastrophic backtracking attacks (ReDoS) commonly found in naive validators.

  1. Lexical Analysis: The JSON payload is parsed strictly (no trailing commas, no unquoted keys).
  2. Reference Resolution: All internal $ref and $dynamicRef pointers are resolved. External references require explicit configuration.
  3. Constraint Application: Type constraints, then structural constraints (properties, items), then format assertions.

Type Mapping & Generation

When using the Code Generator, SchemaInterface applies strict mappings to target languages. Nullable types are handled via Option/Optional wrappers rather than loose typing.

JSON SchemaTypeScriptRust
"type": "string"stringString
"type": ["string", "null"]string | nullOption<String>
"format": "date-time"Datechrono::DateTime

Resolution ($ref) Architecture

Cyclic dependencies in JSON Schema are valid but require careful evaluation. Our engine limits recursion depth to 128 levels by default to prevent stack overflows.

{
  "type": "object",
  "properties": {
    "parent": { "$ref": "#" }
  }
}

Fig 1: A structurally valid self-referential schema representing an infinitely nested tree.