@Jiaz
Quote:
would be great if you chould mix schemes
|
You mean for instance "Have different types of rules (DEEPCRYPT, DIRECTHTTP, etc.) in the same multi-rule array"? Because if it's that, then it's already accounted for

.
The single-rule scheme validates a rule object only to internal consistency. The multi rule-scheme just reuses this as the array-item definition and validates the listed rule objects to their individual internal consistency.
Unless you mean some other scenario(?)
Quote:
define value xy must be valid regex pattern
|
Reading this I remembered that I tried to do it in the definition I was working on, but "format" doesn't seem to be configured as an assertion expression for all possible values stated to be 'builtin' according to spec for the case of VScode's implementation of draft07-onwards. "format":"uri" or "format":"email" work as assertion, "format":"regex" appears to be among the annotation ones. Which is was a strong motivator for me including the "- Type: HTML RegEx" bit in the "description" properties of each rule property. On the "it's not that relevant at this point of user workflow" side, the likely fact that if there was incorrect behaviour from the rule, users would end up putting the regex against the url in the online regex validator itself, which would tell them if the expression was off anyway. So I just left it out.
A small aside is that "format":"regex" validates explicitly against the ES262 regex dialect, I'm not too knowledgeable of the Java flavor but there's probably some construct out there that doesn't translate to the point of breaking the expresion from ES262's viewpoint, hopefully nothing but edge cases that will be caught by regex101.
However, right now, mid-explanation, it prompted my curiosity to see if the online validators had it in their implementation... And lo! They have it

. So I'm gonna add a bunch of "format":"regex" to the definition right away.