Correct handling of / in pattern

[tschmidtb51]

I'm wondering whether the following pattern ^ANY:/[ab]$ is a valid JSON pattern. Many implementations accept it but for example Deno requires to escape the / for it to be valid. So the question is: Is that an issue with the pattern or with deno? How should the spec be interpreted? (I had a look through the spec but was not really successful to resolve the question).

[gregsdennis]

By "Deno" I imagine you mean https://deno.com/? This seems more like a question about how Javascript handles regex rather than a JSON Schema question.

Can you elaborate?

[tschmidtb51]

For clarification:
CSAF: Common Security Advisory Framework - an international, open standard for machine-readable security information (including, but not limited to security advisories, VEX and informational advisories).

[gregsdennis]

We don't control anything about JSON here. We're only JSON Schema, which operates on the JSON data model not on the encoding itself.

That said, it sounds like a bug in Deno to me. / isn't required to be escaped by JSON. It exists in pointers all of the time. I'm not sure about whether a Javascript regex would require it to be escaped, though.

[jdesrosiers]

JSON doesn't have regular expressions, so it has nothing to say about the matter.

JSON Schema has regular expressions expressed as strings. JSON Schema implementations are expected to use whatever regex engine is available in the language the implementation is written in. Since you mention deno, that means this is a JavaScript question. Specifically, the question is, does new Regex() in JavaScript require / to be escaped? I tried it in node.js, deno, and firefox and in all cases, the answer is "no", it does not need to be escaped.

[tschmidtb51]

Thank you for your answer. We will consider your answer. For the future, it would be nice, if that could be clarified in the standard and would not depend upon the implementation. That would make it easier to write a schema that is interoperable with "all" implementations.

[gregsdennis]

Core 6.4 does address the disparity and contains text to encourage compatible expressions.

Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:

• individual Unicode characters, as defined by the JSON specification [RFC8259];
• simple character classes ([abc]), range character classes ([a-z]);
• complemented character classes ([^abc], [^a-z]);
• simple quantifiers: "+" (one or more), "" (zero or more), "?" (zero or one), and their lazy versions ("+?", "?", "??");
• range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most y, occurrences), {x,} (x occurrences or more), and their lazy versions;
• the beginning-of-input ("^") and end-of-input ("$") anchors;
• simple grouping ("(...)") and alternation ("|").

JSON Schema can't require these things for all languages until all languages unify their regex support.