view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        Both "unevaluatedItems" and "unevaluatedProperties" are enforced
        using annotation produced by earlier keyword evaluations within the
        same schema object, matching draft 2020-12 semantics.

    *   Error reporting and pointers

        Each error object contains both:

        *   "path" – a JSON Pointer-like path to the failing location in the
            instance (e.g.
            "#/properties~1s/oneOf~11/properties~1classes/0").

        *   "schema_pointer" – a JSON Pointer into the root schema that
            identifies the keyword which emitted the error (e.g.
            "#/properties~1s/oneOf~11/properties~1classes/items/allOf~10/the
            n/voting_right").

        Messages for "required" errors also list the full required set and
        the keys actually present at that location to help debug combinators
        such as "anyOf"/"oneOf"/"if"/"then"/"else".

    *   RFC rigor and media types

        URI/"IRI" and media‐type parsing is intentionally pragmatic rather
        than fully RFC-complete. For example, "uri", "iri", and
        "uri-reference" use strict but heuristic regexes; "contentMediaType"
        validates UTF-8 for "text/*; charset=utf-8" and supports pluggable
        validators/decoders, but is not a general MIME toolkit.

    *   Compilation vs. Interpretation

        Both code paths are correct by design. The interpreter is simpler
        and great while developing a schema; toggle "->compile" when moving
        to production or after the schema stabilises. You may enable
        compilation lazily (call "compile" any time) or eagerly via the
        constructor ("compile => 1").

WHY ENABLE "COMPILE"?
    When "compile" is ON, the validator precompiles a tiny Perl closure for
    each schema node. At runtime, those closures:

    *   avoid repeated hash lookups for keyword presence/values;

    *   skip dispatch on absent keywords (branchless fast paths);

    *   reuse precompiled child validators (arrays/objects/combinators);

    *   reduce allocator churn by returning small, fixed-shape result
        hashes.

    In practice this improves steady-state throughput (especially for
    large/branchy schemas, or hot validation loops) and lowers tail latency
    by minimising per-instance work. The trade-offs are:

    *   a one-time compile cost per node (usually amortised quickly);

    *   a small memory footprint for closures (one per visited node).

    If you only validate once or twice against a tiny schema, compilation
    will not matter; for services, batch jobs, or streaming pipelines it
    typically yields a noticeable speedup. Always benchmark with your own
    schema+data.

AUTHOR
    Jacques Deguest <jack@deguest.jp>

SEE ALSO
    perl, DateTime, DateTime::Format::ISO8601, DateTime::Duration,
    Regexp::Common, Net::IDN::Encode, JSON::PP

    JSON::Schema, JSON::Validator

    python-jsonschema <https://github.com/python-jsonschema/jsonschema>,
    fastjsonschema <https://github.com/horejsek/python-fastjsonschema>,
    Pydantic <https://docs.pydantic.dev>, RapidJSON Schema
    <https://rapidjson.org/md_doc_schema.html>

    <https://json-schema.org/specification>

COPYRIGHT & LICENSE
    Copyright(c) 2025 DEGUEST Pte. Ltd.

    All rights reserved.

    This program is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.