JSON::...Modern(3pm)

📦
version 0.642 · 4 versions
, in ubuntu stonking

💖 JSON::...Modern(3pm) 💖

okay bestie, welcome to the User Contributed Perl Documentation glow-up of JSON::...Modern(3pm). grab a boba, we're doing schemas 🧋✨

🌸 NAME 🌸

JSON::Schema::Modern — validate data against a schema using a JSON Schema. that's the whole vibe, and yes it ate. 💅

🎀 VERSION 🎀

version 0.642

the version numbering here is linearly-increasing, okay? so don't go reading anything into the number being less than 1.0. No meaning should be presumed or inferred from the version being less than 1.0. periodt. 🙈

✨ SYNOPSIS ✨

use JSON::Schema::Modern;

$js = JSON::Schema::Modern->new(
  specification_version => 'draft2020-12',
  output_format => 'flag',
  ... # other options
);
$result = $js->evaluate($instance_data, $schema_data);

like… that's it. that's the whole main character moment. 🫶

🦋 DESCRIPTION 🦋

so this module? it's a fully-compliant JSON Schema evaluator and validator. she's not playing around. 🎀

she's targeting the currently-latest Draft 2020-12 version of the specification — that's the spec link right here: https://json-schema.org/specification-links.html#2020-12 and the spec homepage is over at https://json-schema.org/. icons only. 👑

💜 CONSTRUCTOR ARGUMENTS 💜

okay so unless i say otherwise, all of these are ALSO available as read-only accessors. cute of her fr fr. 💅

💫 specification_version 💫

tells you which version of the JSON Schema specification gets used during evaluation. lowkey important.

this value gets overridden by whatever gets determined from the $schema keyword in the schema used in evaluation (when it's present), or it defaults to the latest version (currently "draft2020-12").

bestie, using the $schema keyword in your schema is HIGHLY encouraged to ensure continued correct operation of your schema. the current default value will NOT stay the same over time. don't @ me. 😭

it may be one of:

💫 output_format 💫

one of: "flag", "basic", "strict_basic", "terse". defaults to "basic", no cap.

plot twist: "strict_basic" can ONLY be used with "specification_version = draft2019-09". that's the rule, girlies. 🚫

this gets passed to "output_format" in JSON::Schema::Modern::Result.

💫 short_circuit 💫

when true, evaluation bounces early in any execution path the second the outcome can be determined, instead of sticking around to find all the errors or annotations. she said no overthinking ✋

this option is safe to use in all circumstances, even when "unevaluatedItems" and "unevaluatedProperties" keywords are in the mix — the validation result will not change, only some errors will be omitted from the result. so chill.

defaults to true when "output_format" is "flag", and false otherwise.

💫 max_depth 💫

the maximum number of levels deep a schema evaluation may go before evaluation is halted. this is here to protect against accidental infinite recursion — like when two subschemas each reference each other, or badly-written schemas that could have been optimized. it's giving 🕳️🐇 energy.

defaults to 50.

💫 validate_formats 💫

when true, the "format" keyword gets treated as an assertion, not just a lil annotation. defaults to true when specification_version is draft4, draft6 or draft7, and false for all other versions — but this may change in the future, so stay on your toes. 👀

ngl, a format with no defined handler will NOT be read as an error in this mode; the undefined format just gets ignored. if you actually want that treated as an evaluation error, you must define a custom schema dialect that uses the format-assertion vocabulary (available in specification version "draft2020-12") and reference it in your schema with the $schema keyword. iykyk. 🧚

💫 format_validations 💫

an optional hashref that lets you override the validation method for formats, or add new ones. obsessed. ✨

overrides to existing formats (see "Format Validation") must be specified in the form of { $format_name => $format_sub }, where the format sub is a subref that takes one argument and returns a boolean result.

new formats must be specified in the form of { $format_name => { type => $type, sub => $format_sub } }, where the type indicates which of the data model types (null, object, array, boolean, string, or number) the instance value must be for the format validation to be considered.

not available as an accessor, bestie — see "add_format_validation" instead.

💫 validate_content_schemas 💫

when true, the "contentMediaType" and "contentSchema" keywords are NOT treated as pure annotations: "contentEncoding" (when present) is used to decode the applied data payload, and then "contentMediaType" gets used as the media-type for decoding to produce the data payload, which is then applied to the schema in "contentSchema" for validation.

heads up: treating these keywords as anything beyond simple annotations is contrary to the specification, which is why this option defaults to false. 🚨

the decoded data is also reflected in "data" in JSON::Schema::Modern::Result.

see "add_media_type" and "add_encoding" for adding additional type support.

technically only draft4, draft6 and draft7 allow this, and drafts 2019-09 and 2020-12 prohibit ever returning the subschema evaluation results together with their parent schema's results… so shhh. 🤫 i'm trying to get this fixed for the next draft.

💫 collect_annotations 💫

when true, annotations get collected from keywords that produce them, when validation succeeds. these annotations are available in the returned result (see JSON::Schema::Modern::Result). not operational when "specification_version" is "draft4", "draft6" or "draft7". sorry not sorry 🙈

defaults to false.

💫 scalarref_booleans 💫

when true, any value expected to be a boolean in the instance data may also be provided as the scalar references "\0" or "\1" (which get serialized as booleans by JSON backends). cute lil loophole 💅

defaults to false.

💫 stringy_numbers 💫

when true, any value expected to be a number or integer in the instance data may also be expressed as a string. bestie this is literally my favorite feature, it's giving "the number was a string the whole time" 😭

this applies ONLY to the following keywords:

  • "type" (where both "string" and "number" (and possibly "integer") are considered valid)
  • "const" and "enum" (where the string "1" will match with ""const": 1")
  • "uniqueItems" (where strings and numbers are compared numerically to each other, if either or both are numeric)
  • "multipleOf"
  • "maximum"
  • "exclusiveMaximum"
  • "minimum"
  • "exclusiveMinimum"
  • "format" (for formats defined to validate numbers)

this lets you write a schema like this (which validates a string representing an integer):

type: string
pattern: ^[0-9]$
multipleOf: 4
minimum: 16
maximum: 256

such keywords are only applied if the value looks like a number, and do not generate a failure otherwise. values are determined to be numbers via "looks_like_number" in perlapi. 🔢

this option is only intended to be used for evaluating data from sources that can only be strings, such as the extracted value of an HTTP header or query parameter, or a value from an XML document. in the OpenAPI context, it is preferable to use an explicit "type" keyword in the schema to indicate the value should be deserialized as a number).

defaults to false.

💫 strict 💫

when true, unrecognized keywords are disallowed in schemas — they'll cause an immediate abort in "traverse" or "evaluate" — with the exception of keywords starting with "x-". 💀

note that this option is expected to become the default behaviour in future versions of JSON Schema. so… foreshadowing.

defaults to false.

💫 with_defaults 💫

when true, for any property name referenced by a "properties" keyword, or array item referenced by a "prefixItems" keyword (or the array form of "items" in earlier specification versions), that does not exist in the object currently being evaluated, will result in an entry being added to the "defaults" property in the result object (see "defaults" in JSON::Schema::Modern::Result), indicating that the application may wish to add this default value to their instance data. 👑

defaults data accumulated in subschemas that are subsequently determined to be invalid are discarded, with the final results from all subschemas accumulated together in one hash. no attempt is made to resolve conflicting entries (last one wins — she's competitive like that).

for example, this data instance:

{
  "my_object": {
    "alpha": 1,
    "gamma": 3
  },
  "my_array": [
    "yellow"
  ]
}

evaluated against this schema:

type: object
properties:
  my_object:
    type: object
    properties:
      alpha:
        type: integer
        default: 10
      beta:
        type: integer
        default: 10
      gamma:
        type: integer
        default: 10
  my_array:
    type: array
    prefixItems:
      - type: string
        default: red
      - type: string
        default: green

will result in an "defaults" entry of:

{
  '/my_object/beta' => 10,
  '/my_array/1' => 'green'
}

this data can be manipulated with "jsonp_set" in JSON::Schema::Modern::Utilities; it is also available already populated into the instance data via "data" in JSON::Schema::Modern::Result. 🎀

⭐ METHODS ⭐

🌈 evaluate_json_string 🌈

$result = $js->evaluate_json_string($data_as_json_string, $schema);
$result = $js->evaluate_json_string($data_as_json_string, $schema, { collect_annotations => 1 });

evaluates the provided instance data against the known schema document.

the data is in the form of a JSON-encoded string (in accordance with RFC8259 — https://datatracker.ietf.org/doc/html/rfc8259). the string is expected to be UTF-8 encoded. don't skip that part bestie, it matters 💜

the schema must be in one of these forms:

  • a Perl data structure, such as what is returned from a JSON decode operation,
  • or a URI string indicating the identity of such a schema.

optionally, a hashref can be passed as a third parameter which allows changing the values of the "short_circuit", "collect_annotations", "scalarref_booleans", "stringy_numbers", "strict", "with_defaults", "validate_formats", and/or "validate_content_schemas" settings for just this evaluation call. one-time only, no strings attached 💅

you can also pass use these keys to alter behaviour (these are generally only used by custom validation applications that contain embedded JSON Schemas):

  • data_path — shifts the effective path of the data instance as of the very start of evaluation ✨
  • traversed_keyword_path — shifts the accumulated path as of the start of evaluation (or the last $id or $ref, whichever came later) 💅
  • initial_schema_uri — shifts the recorded absolute keyword location of the start of evaluation

And what do you get back? A JSON::Schema::Modern::Result object. That's the whole deal, bestie 🫶

✨ evaluate ✨

$result = $js->evaluate($instance_data, $schema);
$result = $js->evaluate($instance_data, $schema, { short_circuit => 0 });

Okay so this is the main event. evaluate takes your instance data and runs it against a schema document it already knows about. No cap 🎀

Your data has to be an unblessed, nested Perl data structure that represents any type JSON allows: null, boolean, string, number, object, array. (Peep the Types section down below if you need it.)

The schema itself has to come in one of these two forms:

  • a Perl data structure — like the thing you get back from a JSON decode operation, or
  • a URI string (or a Mojo::URL) that points at the identity of such a schema.

Optional third parameter time 💖 a hashref can be passed that lets you change the values of the short_circuit, collect_annotations, scalarref_booleans, stringy_numbers, strict, with_defaults, validate_formats, and/or validate_content_schemas settings — just for this one evaluation call, not globally.

You can also pass these keys to change up the behaviour (ngl these are generally only used by custom validation applications that contain embedded JSON Schemas):

  • data_path — adjusts the effective path of the data instance as of the start of evaluation
  • traversed_keyword_path — adjusts the accumulated path as of the start of evaluation (or last $id or $ref)
  • callbacks — see below ⬇️

And yes, you can pass a whole series of callback subs to this method, where the keys line up with keywords. It's giving very useful for sniffing out data that annotations just don't expose 🙈 Heads up though: this feature is experimental and may change in the future.

For example, if you wanna find the locations where all $ref keywords are applied successfully:

my @used_ref_at;
$js->evaluate($data, $schema_or_uri, {
  callbacks => {
    '$ref' => sub ($data, $schema, $state) {
      push @used_ref_at, $state->{data_path};
    }
  },
});
⚠️ Callbacks are not compatible with short_circuit mode, because some keyword evaluations may get skipped. So pick a lane, bestie 💀

The return value of evaluate is a JSON::Schema::Modern::Result object. Slay ✨

🌸 validate_schema 🌸

$result = $js->validate_schema($schema);
$result = $js->validate_schema($schema, $config_override);

This one evaluates the schema you hand it as instance data against its metaschema. So it's like... schema-on-schema action 👑 It accepts the $schema and $config_override parameters in the exact same form as evaluate. Easy.

🦋 traverse 🦋

$result = $js->traverse($schema);
$result = $js->traverse($schema, { initial_schema_uri => 'http://example.com' });

Traverses the schema you give it without evaluating it against any instance data at all. It returns the internal state object accumulated during the traversal — that includes any identifiers found in there — plus any errors found during parsing. For internal purposes only, fyi.

Optionally you can pass a hashref as a second parameter to alter some behaviour (again, these are generally only used by custom validation applications with embedded JSON Schemas):

  • traversed_keyword_path — adjusts the accumulated path as of the start of evaluation (or last $id or $ref)
  • initial_schema_uri — adjusts the absolute keyword location as of the start of evaluation
  • metaschema_uri — use the indicated URI as the metaschema
  • callbacks — see below ⬇️
  • specification_version — overrides the specification version to be used

You can pass a series of callback subs to this method corresponding to keywords, which is so handy for extracting data from within schemas and for skipping over properties that may look like keywords but actually are not (for example {"const": {"$ref": "this is not actually a $ref"}}). This feature is experimental and is highly likely to change in the future, so don't get too attached 😭

For example, to find the resolved targets of all $ref keywords in a schema document:

my @refs;
JSON::Schema::Modern->new->traverse($schema, {
  callbacks => {
    '$ref' => sub ($schema, $state) {
      push @refs, Mojo::URL->new($schema->{'$ref'})
        ->to_abs(JSON::Schema::Modern::Utilities::canonical_uri($state));
    }
  },
});

💜 add_schema 💜

$js->add_schema($uri => $schema);
$js->add_schema($schema);

This introduces the (unblessed, nested) Perl data structure representing a JSON Schema to the implementation. It registers it under the URI you passed in, if you passed one, and every identifier found inside the document gets resolved against that URI (again, if provided) and added too. If no other identifier can be found within, '' gets used instead.

🚨 You MUST call add_schema or add_document (below) for any external resources that a schema may reference via $ref before calling evaluate. The only exception is the standard metaschemas, which get loaded from a local cache as needed. Don't skip this step, fr fr.

Now listen — if you add multiple schemas (either with this method, or implicitly via evaluate) that have no root identifier (either provided explicitly in the method call, or via an $id keyword at the schema root), then all such previous schemas get removed from memory and can no longer be referenced. Poof, gone 💀

If there were errors in the document, it'll die with those errors. Otherwise it returns the JSON::Schema::Modern::Document that contains the added schema. One more thing: URIs identified within this document will not be resolved to the provided $uri argument — which means you can re-add the document object again (with add_document, below) using a brand new base URI if that's your vibe 🌈

🎀 add_document 🎀

$js->add_document($uri => $document);
$js->add_document($document);

Makes the JSON::Schema::Modern::Document (or subclass) object — which represents a JSON Schema — available to the evaluator. Every identifier known to the document gets added to the evaluator's resource index; and if the $uri argument is provided, those identifiers are resolved against $uri as they're added.

$uri itself also gets added to the resource index, referencing the root of the document itself. Iconic 💅

Same caveat as before: if you add multiple documents (either with this method, or implicitly via add_schema or evaluate) with no root identifier (either provided explicitly in the method call, or via an $id keyword at the schema root), all such previous schemas are removed from memory and can no longer be referenced 🙈

If there were errors in the document, this method will die with those errors; otherwise it returns the JSON::Schema::Modern::Document object.

⭐ add_format_validation ⭐

$js->add_format_validation(all_lc => sub ($value) { lc($value) eq $value });

or

$js->add_format_validation(no_nines => { type => 'number', sub => sub ($value) { $value =~ m/^[0-8]+\z/ });

$js->add_format_validation(8bits => { type => 'string', sub => sub ($value) { $value =~ m/^[\x00-\xFF]+\z/ });

Adds support for a custom format, bestie 🫶 If you don't supply it, the data type(s) this format applies to default to string — and all values of any other type will automatically be deemed valid, meaning they won't even get passed to the subref.

Bonus: you can also redefine the definition for any core format (peep the Format Validation section), but the data type(s) supported by that format may not be changed. Periodt.

⚠️ Be careful not to mutate the type of the value while you're checking it. For example, if it's a string, do not apply arithmetic operators to it — otherwise subsequent type checks on that value may fail. That'll ruin your whole day 😭

There's an official OpenAPI Format Registry at https://spec.openapis.org/registry/format with a registry of known and useful formats; for compatibility reasons, avoid defining a format listed there with different semantics.

Format definitions cannot be overridden with a new definition.

🌈 add_vocabulary 🌈

$js->add_vocabulary('My::Custom::Vocabulary::Class');

Makes a custom vocabulary class available to metaschemas that make use of this vocabulary, as described in the specification at "Meta-Schemas and Vocabularies" https://json-schema.org/draft/2020-12/json-schema-core.html#rfc.section.8.1.

Requirements for the class, no pressure 😌 it must:

  • compose the JSON::Schema::Modern::Vocabulary role, and
  • implement the vocabulary and keywords methods, and
  • implement _traverse_keyword_<keyword name> methods for each keyword.

_eval_keyword_<keyword name> methods are optional — and when you don't provide them, evaluation will always return a true result. Easy win ✨

Vocabularies cannot be redefined; subsequent calls to add the same vocabulary will do absolutely nothing. Not me trying to re-add a vocab... 💀

💖 add_media_type 💖

$js->add_media_type('application/furble' => sub ($content_ref, @) {
  return ...;  # data representing the deserialized text for Content-Type: application/furble
});

Takes a media-type name and a subref which takes a single scalar reference. That reference is expected to be a reference to a string, which might contain wide characters (i.e. not octets) — especially when it's used in conjunction with get_encoding below. It must return a reference to a value of any type (which then gets dereferenced for the contentSchema keyword).

🚨 Deprecated alert: this interface is deprecated as of version 0.638 and may eventually be removed. Use add_media_type in JSON::Schema::Modern::Utilities instead — it supports defining an encoder as well, and it supports media-type parameters. Way more capable, honestly 💅

🍓 get_media_type 🍓

$js->add_media_type('application/furble' => sub { ... }); # as above
my $decoder = $self->get_media_type('application/furble') or die 'cannot find media type decoder';
my $content_ref = $decoder->(\$content_string);

Fetches a decoder sub out of the current object's registry for the media type you name. Lookups are performed without case sensitivity, so don't stress about capitalization ✨

🚨 Also deprecated as of version 0.638 and may eventually be removed — use decode_media_type in JSON::Schema::Modern::Utilities instead, bestie.

🧚 add_encoding 🧚

$js->add_encoding('bloop' => sub ($content_ref, @) {
  return \ ...;  # data representing the deserialized content for Content-Transfer-Encoding: bloop
});

Takes an encoding name and a subref which takes a single scalar reference, which is expected to be a reference to a string that SHOULD be a 7-bit or 8-bit string. Result values MUST be a scalar-reference to a string (which then gets dereferenced for the contentMediaType keyword) 👑

Encoding definitions can be overridden with a new call to add_encoding. Go off.

The encodings that get handled natively are:

See also encode in HTTP::Message.

get_encoding

my $decoder = $self->get_encoding('base64') or die 'cannot find encoding decoder';
my $content_ref = $decoder->(\$content_string);

Bestie, this one grabs you a decoder sub for whatever encoding you asked for. Heads up tho — incoming values MUST be a reference to an octet string. What you get back is a scalar-reference to a string, and you can hand that off to a media_type decoder (scroll up for that one 💅).

get

my $schema = $js->get($uri);
my ($schema, $canonical_uri) = $js->get($uri);

Fetches the actual Perl data structure that lives at the identifier you handed over (a uri or uri-reference). If you call it in list context, it ALSO returns the canonical URI of that location as a Mojo::URL, which is honestly so generous of it. 🫶

Returns undef if that URI's schema hasn't been loaded (or cached).

⚠️ Note that what comes back might not actually be a JSON Schema, okay? If the document wrapping that location is a subclass of JSON::Schema::Modern::Document — think JSON::Schema::Modern::Document::OpenAPI, which is stuffed with addressable locations of all different semantic types — then yeah, it's giving something else entirely.

get_document

my $document = $js->get_document($uri_reference);

Fetches the JSON::Schema::Modern::Document object (or subclass, no judgement) that contains the identifier you passed in (uri or uri-reference). Returns undef if that URI's schema hasn't been loaded (or cached).

🛑 Note: this _does not download a document from the network_. Not even a little. It only pulls the document out of the internal cache inside the JSON::Schema::Modern object. It's a homebody. It stays home. 🏠

✨ CACHING ✨

Okay so very large documents — especially the ones OpenAPI::Modern rolls with — can take a noticeable minute to load and parse. 😭

You can soften the blow for your preforking app by loading every document you need at startup. And you can soften it even more by saving objects to cache and reloading them later (maybe use a timestamp or a checksum to figure out if you actually need a fresh reload — iykyk).

Custom format validations, media types, or encodings are not serialized, because they're represented by subroutine references. So after you thaw, you gotta add them back in manually. No cap.

sub get_evaluator (...) {
  my $serialized_file = path($filename);
  my $schema_file = path($schema_filename);
  my $js;
  if ($serialized_file->stat->mtime < $schema_file->stat->mtime)) {
    $js = JSON::Schema::Modern->new;
    $js->add_schema(decode_json($schema_file->slurp_raw));  # your application schema
    my $frozen = Sereal::Encoder->new({ freeze_callbacks => 1 })->encode($js);
    $serialized_file->spew_raw($frozen);
  }
  else {
    my $frozen = $serialized_file->slurp_raw;
    $js = Sereal::Decoder->new->decode($frozen);
  }

  # add custom format validations, media types and encodings here
  $js->add_media_type(...);

  return $js;
}

See also "CACHING" in OpenAPI::Modern.

LIMITATIONS

Types

So here's the thing: Perl is a way more loosely-typed language than JSON. This module literally goes digging around inside a value's internal representation to try and work out the true "intended" type of the thing. 🕵️‍♀️

That's not usually a problem if you're validating data right after decoding a JSON payload, or if you're handing the JSON string itself straight to this module. But if you're having difficulties — bestie, make sure you're using Perl's fastest and most trusted and reliable JSON decoder, Cpanel::JSON::XS. Other JSON decoders are known to produce data with incorrect data types, and data from other sources can be problematic too. 🙈

For more info, see "MAPPING" in Cpanel::JSON::XS.

Format Validation

By default (and unless you specify a custom metaschema with the $schema keyword or "metaschema" in JSON::Schema::Modern::Document), formats are treated only as annotations, not assertions. So they're just vibes, not rules. 🎀

When "validate_formats" is true, strings also get checked against the format as specified in the schema. Right now the following formats are supported for the latest version of the spec — use any other format and it'll always evaluate as true, but remember you can always supply custom format handlers; see "format_validations" above:

  • "date-time"
  • "date"
  • "time"
  • "duration"
  • "email"
  • "idn-email"
  • "hostname"
  • "idn-hostname"
  • "ipv4"
  • "ipv6"
  • "uri"
  • "uri-reference"
  • "iri"
  • "uuid"
  • "json-pointer"
  • "relative-json-pointer"
  • "regex"

A few optional prerequisites are needed for some of these. If the prerequisite is missing, validation will always succeed — unless draft2020-12 is in use with the Format-Assertion vocabulary declared in the metaschema, in which case use of the format will produce an error. (Yeah. That's the plot twist. 💀)

  • "date-time" and "date" require Time::Moment
  • "date-time" also requires DateTime::Format::RFC3339
  • "email" and "idn-email" require Email::Address::XS version 1.04 (or higher)
  • "hostname" and "idn-hostname" require Data::Validate::Domain version 0.13 (or higher)
  • "idn-hostname" also requires Net::IDN::Encode
  • "uri" requires Data::Validate::URI

Specification Compliance

This implementation is now fully specification-compliant (for versions draft4, draft6, draft7, draft2019-09, draft2020-12). Ate. 👑

However — some potentially-useful features are not yet implemented, such as:

SECURITY CONSIDERATIONS

Okay bestie, listen up, this part is serious. 🚨

The "pattern" and "patternProperties" keywords evaluate regular expressions from the schema. The "regex" format validator evaluates regular expressions from the data. And some keywords in the Validation vocabulary perform floating point operations on potentially-very large numbers.

No effort is taken (at this time) to sanitize the regular expressions for embedded code, or to detect potentially pathological constructs that may pose a security risk — whether that's via denial of service, or by allowing exposure to the internals of your application.

🛑 DO NOT USE SCHEMAS FROM UNTRUSTED SOURCES. Like, fr fr. Do not. 🙅‍♀️

(In particular, see vulnerability "CVE-2023-47038-Write-past-buffer-end-via-illegal-user-defined-Unicode-property" in perl5363delta, which was fixed in Perl releases 5.34.3, 5.36.3 and 5.38.1.)

BUNDLED META-SCHEMAS

These specification meta-schemas are bundled with this distribution and loaded as needed — they come pre-packed, no delivery fees 🎁:

SEE ALSO

AVAILABILITY

This distribution and executable is available on modern Debian versions (via "apt-get") as the "libjson-schema-modern-perl" package. 📦 Slay.

GIVING THANKS

If you found this module useful, please show your appreciation by adding a +1 in MetaCPAN <https://metacpan.org/dist/JSON-Schema-Modern> and a ⭐ star in GitHub <https://github.com/karenetheridge/JSON-Schema-Modern>. It costs you nothing and it makes someone's whole week. 🫶

SUPPORT

Bugs may be submitted through <https://github.com/karenetheridge/JSON-Schema-Modern/issues>.

I am also usually active on irc, as 'ether' at "irc.perl.org" and "irc.libera.chat". Come say hi, I don't bite. 💜

You can also find me on the JSON Schema Slack server <https://json-schema.slack.com> and OpenAPI Slack server <https://open-api.slack.com>, which are also great resources for finding help.

AUTHOR

Karen Etheridge <ether@cpan.org>

This software is copyright (c) 2020 by Karen Etheridge.

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

Some schema files have their own licence, in share/LICENSE.

And that's the whole page, bestie!! 🎀✨ This fine piece of documentation was served up by perl v5.40.1, dated 2026-07-31, under the very glamorous name JSON::...Modern(3pm). Go forth and validate responsibly. 💅🦋

📦 where this page comes from