Add a test for "regex"es that use \a (ASCII BEL)

[leadpony]

Hello
The 4th and 5th test cases defined in ecmascript-regex.json use the following pattern keyword in the input schema.

"pattern": "^\\a$"

The ECMA-262 specification does not allow a as a letter for control escape in its syntax definition.

ControlEscape :: one of 
  f n r t v

I tested it with Node.js as follows:

node
Welcome to Node.js v12.13.1.
Type ".help" for more information.
> var re = new RegExp('^\\a$');
undefined
> re.test('\u0007');
false

The test case in ecmascript-regex.json seems incompatible with the test() result above.
How should we treat these test cases?

[Julian]

Seems you're right to me from what I can tell.

@Zac-HD might be able to weigh in having presumably just read through that spec, but assuming you're right here, probably worth changing that one to use one of the other escape characters, and then explicitly adding one saying \a isn't valid.

[leadpony]

I would like to hear the initial intention of the test from @Zac-HD if possible.
I would rather not break it.

[Zac-HD]

We should switch as @Julian suggests; I was just more familiar with the Python than the ECMA string escapes.

[leadpony]

@Julian @Zac-HD
Thank you for your quick responses.
Switching \\a to another escape such as \\t is OK, however, leaving test with \\a may create another problem.

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

1. 21.2 RegExp (Regular Expression) Objects
2. 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.

[Julian]

Thanks for doing the research. Seems like probably something to raise upstream on the spec if there's missing clarity then yeah.

[Julian]

(At which point we can probably just decouple the two of these things -- immediately change the \a in a PR, and then just file an issue to add a test for \a's behavior one way or the other as soon as the spec clarifies it)

Sound reasonable?

[Julian]

Filed json-schema-org/json-schema-spec#821 -- we can leave this ticket open until the upstream issue is clarified, and then add a test for the decided upon behavior.

[ChALkeR]

@Julian e42e841 introduces a schema that's invalid afaik, and the test expects that schema to fail validation on input it receives, which is different.

I think that the correct behavior would be to refuse to compile (or load) this schema at all, not just fail everything in runtime.
That's not what that test is checking.

Upd: ah, ignore me, I misread, that's in data, not schema! Sorry for the noise.

[karenetheridge]

For more complete coverage, you could test "format": "regex" against the data instance "\a".