In furtherance of B2B Global Standards

[JPMinAR]

Has JSON Schema considered including a format check for numbers with check digits. There are so many things passed via JSON that are aligned with some GS1, Banking, Card, or other standard that go beyond mere checks that RegEx can preform. This impacts much of B2B exchanges incluing GTIN (formerly UPC/EAN), Shipping Container Unique IDs (SSCC), Credit Cards, IMEI, and other and the list if relatively short.

For the most part all Check digits fall under one of two ISO standards and the later all the varitions can be defined but Mod+Radix definitions.

The following could be checked against integer or string types as numberic values.

ISO7812-1AnnexB - also known as Luhn Formula, Mod 10 used in almost all GS1 standards included GTIN, SSCC, GDSN, and more.
ISO7074Mod11Radix10
ISO7064Mod11Radix2

The rest would only be string validations with limited character sets in addition to the check digit calculation.

ISO7064Mod37Radix2
ISO7064Mod661Radix26
ISO7064Mod1271Radix36

The addition of just these few would go a long ways towards JSON Schema having some great B2B application and extending JSON furture within the API space across multiple industries.

[gregsdennis]

Standardizing these things would be great, however, it's not strictly the purview of JSON Schema to do this as it is somewhat industry targeted.

My suggestion, with the specification in its current state (2020-12), would be to create a new vocabulary that defines new format values and requires assertion.

format, by default, is only an annotation. That means its value is passed to back to the caller for them to deal with. However, there is a format assertion vocabulary that, if included in the meta-schema's $vocbaulary keyword, requires format to be validated. Your vocabulary would provide a similar function.

You can take a look at my custom vocabularies to see what goes into building one.

• https://docs.json-everything.net/schema/vocabs/data-2023/
• https://docs.json-everything.net/schema/vocabs/array-ext/

The following could be checked against integer or string types as numberic values.

Ordinarily I would avoid encoding numeric values in strings, but I think this would be a rare exception. These aren't really numeric values, although they're often expressed using solely digits.

I would always encode these in strings since numbers often hit limitations when interacting with programming languages and exact representation is paramount for these cases. (JSON can handle it, but most programming languages would mangle it.)