|
First, regarding the regex flags: In JSON Schema land, the "regex keys" must be specified as strings. How would you specify flags in a string? Can PCRE properly parse the string
into the regex
or does it literally interpret the slashes? I'm looking at other implementations to see how they approach this particular problem, though when I was looking at example schemas, I hadn't seen any that use flags in patternProperties.
Second, I think being top-level only is not an option. In JSON Schema, this is allowed at any level.
{
|
patternProperties: {
|
"^address": {
|
patternProperties: {
|
"^street": {...},
|
"^avenue": {...},
|
}
|
},
|
"^phone": {...}
|
}
|
}
|
|
|
The <regex-map-object> part might be problematic, since it encodes a regular expression inside a BSON field name. According to the JSON Schema spec section 6.19:
Each property name of this object SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect.
As far as I can tell from https://www.ecma-international.org/ecma-262/5.1/#sec-7.8.5, this means that the regular expression can contain both a body and flags, as in /body/flags. kyle.suarez, does this sound right to you? If so, I think we need this to be an array of two-element arrays. For example,
{$_internalSchemaPatternProperties: [[/^foo/i, <MatchExpression>], [/bar$/i, <MatchExpression>]]}
|
Another concern is that I don't think this should ever come after a path name, as in { <field>: { $_internalSchemaPatternProperties: <regex-map-object> } }. Instead, I think this should always be top-level, in the sense that in the grammar it is a sibling of expressions like $or and $and.
|