Add Unicode-focused tests for string length and pattern handling

[Shristibot]

Summary

Right now, string-related keywords like minLength, maxLength, pattern, and propertyNames don’t have much coverage for Unicode strings that clearly exercise the spec’s “length in Unicode code points” semantics. Most Unicode-related cases live in optional/non-bmp-regex.json and optional/ecmascript-regex.json, and those focus more on regex engine features than on core length and basic Unicode handling.

Motivation

• The validation spec and accompanying docs define minLength/maxLength in terms of Unicode code points, not bytes, and they use Unicode examples to illustrate this.
• In practice, implementations often differ when non‑ASCII text is involved, so having a few explicit tests helps confirm that validators are using code‑point length as required.
• The existing optional regex tests show that engine‑specific behaviour is already isolated under optional/, which leaves room for a small number of portable Unicode examples in the core suite.

Proposal

1. Required tests (core)

• Extend tests/*/minLength.json and maxLength.json (for drafts like draft2020‑12 and later) with cases where:

    - Non‑ASCII strings (for example, simple emoji or common non‑Latin text) sit right at or around the length boundary,                making the code‑point counting explicit.
    - The same numeric minLength/maxLength is applied to both ASCII and non‑ASCII examples, so it’s clear that both are measured in code points rather than bytes.
  

• Extend pattern.json and propertyNames.json with a few straightforward Unicode examples where:

    -  Patterns match literal Unicode characters without relying on flags or advanced Unicode properties.
    -  propertyNames includes keys that contain Unicode letters, again without depending on engine‑specific behaviour.
  

2.Optional tests

• Under tests/*/optional/ (next to non-bmp-regex.json and ecmascript-regex.json), add a small set of tests for more advanced Unicode scenarios—things like zero‑width characters, combining marks, or RTL sequences—where behaviour is more tied to the regex engine.
• These would be clearly marked as optional and aimed at implementations that want to exercise richer Unicode/regex support beyond what the core spec strictly requires.

Required tests should stay within behaviour clearly mandated by the spec (no grapheme‑cluster rules or engine‑specific flags), with more advanced Unicode and regex behaviour covered under optional/ instead.

[Shristibot]

I’d like to work on this.

Plan:

• Review minLength.json, maxLength.json, pattern.json, and propertyNames.json across the supported drafts to see where Unicode examples are missing.
• Open an initial PR for one draft (likely draft2020‑12) adding a small set of Unicode examples for minLength/maxLength (code‑point-based length) plus a few simple Unicode cases in pattern and propertyNames that avoid special regex features.
• Optionally add a couple of related tests under optional/, following the style of non-bmp-regex.json and ecmascript-regex.json

[jdesrosiers]

I think this minLength/maxLength are already covered sufficiently. Here's an example from the minLength tests. maxLength has a similar test.

propertyNames is irrelevant to this issue. Its value is a schema. That schema might include pattern, but that would be covered by the pattern tests. It isn't related to propertyNames.

However, adding tests for unicode in pattern and patternProperties in draft-2020-12 makes sense. Draft-2020-12 was when using unicode mode became required. You can go ahead and add tests for those two keywords for draft-2020-12 only.

[Shristibot]

I think this minLength/maxLength are already covered sufficiently. Here's an example from the minLength tests. maxLength has a similar test.

propertyNames is irrelevant to this issue. Its value is a schema. That schema might include pattern, but that would be covered by the pattern tests. It isn't related to propertyNames.

However, adding tests for unicode in pattern and patternProperties in draft-2020-12 makes sense. Draft-2020-12 was when using unicode mode became required. You can go ahead and add tests for those two keywords for draft-2020-12 only.

Thanks for the clarification! I’ll focus on adding Unicode tests for pattern and patternProperties in draft-2020-12 only, keeping them limited to simple literal Unicode characters without relying on advanced regex features.

[abhi-03-kh]

Hi, I saw the clarification about focusing on pattern and patternProperties for draft-2020-12 only.

I’d like to contribute a small set of literal Unicode tests for those keywords, aligned with the required Unicode mode semantics introduced in draft-2020-12. Happy to coordinate to avoid overlap.