Clarify which regular expression production rule from the ECMA specification is intended

[Julian]

Via @leadpony in json-schema-org/JSON-Schema-Test-Suite#309 [the context being "what behavior is expected if one uses \a, i.e. ASCII BEL, within a regular expression]:

There exist 2 regular expression patterns defined in the ECMA-262 specification.

21.2 RegExp (Regular Expression) Objects
B.1.4 Regular Expressions Patterns

Note that the latter pattern is a part of B. Additional ECMAScript Features for Web Browsers.

Both patterns do not allow a as a controll escape letter, but the final consequence seems to slightly differ.
In the latter pattern, \a is converted to a letter a, as Node.js does, because the letter is recognized as a part of IdentifyEscape.
In the former pattern, I believe a syntax error should be thrown, because a has an ID_CONTINUE Unicode property and cannot be handled as an IdentifyEscape.

IdentityEscape::
SourceCharacter but not UnicodeIDContinue

The JSON Schema Specification does not state which pattern should be followed, therefore we cannot make the test without some ambiguity.

We should clarify which behavior is intended, and therefore whether such a string is or is not a valid regex for the test suite.

[handrews]

@Julian I thought we address this in https://github.com/json-schema-org/json-schema-spec/pull/775/files

[Julian]

A ha, that does certainly seem relevant -- possibly the confusion leftover though is that section doesn't appear in the version of the ECMA262 spec that's linked -- that section from your PR looks like it refs 2011 ECMA spec, but the one linked in the current JSON Schema spec links the 2018 one -- though presumably the intention is the corresponding section in the new version of the spec I guess? Which probably answers the original question here (I think meaning \a should be an error, but will have to double check)

[Relequestual]

We should specify which "edition" of ECMA262 we are referencing.
The 2011 version was "edition 5.1" and the latest now that we link to is "edition 10".

Which version do we want to reference?

[Relequestual]

I think to work this out, we should consider:

• Which version has the broadest out of the box (browser and node) support.
• What are the changes from the current version we intened (ES5.1) to whatever we pick now (ESWHATNOW?)

[Relequestual]

Interestingly, OAS 3.0 references ECMA 262 sec-7.8.5 (https://www.ecma-international.org/ecma-262/5.1/#sec-7.8.5). A literal includes flags.

[MikeRalphson]

In the unreleased v3.0.3 this should have been fixed by PR OAI/OpenAPI-Specification#1987

[Relequestual]

I haven't been able to easily determine what the differences / changes to the relevent sections of the document from edition 5.1 to edition 10... at least no one is telling me and reading to find out will be time consumig!

[brettz9]

Not sure if this should be filed as a separate issue, but I think it would be convenient to allow specifying a format for regex strings which include delimiters and flags, e.g., /abc/im. I presume this is not the current format, and I guess it would need a new format like delimited-regex (unless the lack of slash escaping were used to interpret this as a delimited regex rather than a failing regex).

[karenetheridge]

Definitely another issue, and please don't invent yet another syntax when there are existing ones. https://www.regular-expressions.info/refmodifiers.html

[brettz9]

Ok re: separate issue, but given that the format is currently defined as matching ECMAScript and ECMAScript doesn't support such modifiers, I think it makes far more sense to use a pattern consonant with JavaScript, the regex literal.