More schema hardening

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: This PR further hardens and clarifies multiple standard JSON Schemas, primarily by tightening validation rules, simplifying overly long regexes, and expanding test coverage for edge cases.

Changes:

• POSIX pathname schema is simplified to a single string constraint disallowing NUL bytes; absolute/relative path schemas remain available.
• Removed redundant “control character” exclusions from schemas whose primary patterns already forbid those characters (e.g., base16, HTTP method, RFC 3066 tag syntax).
• Refined the RFC 3986 URL schema to exclude rootless-scheme URIs by requiring the post-scheme character to be /, ?, #, or end-of-string.
• Added an extra standards link for URNs and clarified ISO 4217 “historical” currency titles/descriptions (and updated templates accordingly).
• ISO 8601 calendar date (extended) switches from a bespoke regex to format: date under the format-assertion dialect (enabling leap-year validation).
• Tightened ISO 8601 alternative ordinal-duration schemas to treat the day field as a quantity capped at its carry-over point and to disallow signed/expanded-year forms.
• Allowed comma as a decimal separator across week/duration/interval/recurrence patterns and simplified many interval/recurrence duration regexes.
• Expanded tests for absolute-zero floors, nested GeoJSON GeometryCollections, empty-host HTTP(S) URLs, grandfathered language-tag casing, URN component constraints, leap days, negative durations, and XML Schema timezone/noncharacter restrictions.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

schemas/2020-12/w3c/xmlschema/2001/any-uri.json:4: The description now says “URI reference”, but the linked XML Schema 1.1 spec and RFC 3987 discussion commonly describe anyURI as covering IRI/LEIRI references; this wording might understate what values are accepted (e.g., internationalized examples below).

Severity: low

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cubic-dev-ai]

4 issues found across 64 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="schemas/2020-12/iso/datetime/2019/duration/ordinal-basic.json">

<violation number="1" location="schemas/2020-12/iso/datetime/2019/duration/ordinal-basic.json:10">
P1: The day portion of the pattern now incorrectly allows `000` as an ordinal day value. Ordinal day numbering starts at 001, not 000, so a value like `P0001000T000000` will be incorrectly accepted. The old pattern's sub-patterns `0[0-9][1-9]` and `0[1-9][0-9]` properly excluded 000, but the simplified `[0-2][0-9]{2}` in the new pattern allows it. Consider using `(?:00[1-9]|0[1-9][0-9]|[12][0-9]{2}|3[0-5][0-9]|36[0-5])` to keep the hardening while preserving the 001–365 range.</violation>
</file>

<file name="test/iso/datetime/2019/date/calendar-extended.test.json">

<violation number="1" location="test/iso/datetime/2019/date/calendar-extended.test.json:252">
P3: Duplicate test case: "Valid - leap day in a century leap year" (2000-02-29) is already covered by the existing test "Valid - 29 February 2000 (leap year)" at line 55. Same input and expected result, different descriptions — no new coverage added.</violation>
</file>

<file name="test/w3c/xmlschema/2001/name.test.json">

<violation number="1" location="test/w3c/xmlschema/2001/name.test.json:643">
P2: Test asserts :name (U+02D0 MODIFIER LETTER TRIANGULAR COLON) is invalid, but XML Schema 2001 Name production includes U+02D0 in NameStartChar range #xF8-#x2FF, so it should be valid. The schema pattern uses a negative lookahead to exclude it, but that exclusion is not part of the W3C spec.</violation>
</file>

<file name="schemas/2020-12/w3c/xmlschema/2001/any-uri.json">

<violation number="1" location="schemas/2020-12/w3c/xmlschema/2001/any-uri.json:4">
P3: This description narrows `anyURI` to a URI reference, but XML Schema defines `anyURI` as an IRI reference. Updating the wording to IRI avoids implying internationalized references are out of scope.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: The day portion of the pattern now incorrectly allows 000 as an ordinal day value. Ordinal day numbering starts at 001, not 000, so a value like P0001000T000000 will be incorrectly accepted. The old pattern's sub-patterns 0[0-9][1-9] and 0[1-9][0-9] properly excluded 000, but the simplified [0-2][0-9]{2} in the new pattern allows it. Consider using (?:00[1-9]|0[1-9][0-9]|[12][0-9]{2}|3[0-5][0-9]|36[0-5]) to keep the hardening while preserving the 001–365 range.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At schemas/2020-12/iso/datetime/2019/duration/ordinal-basic.json, line 10:

<comment>The day portion of the pattern now incorrectly allows `000` as an ordinal day value. Ordinal day numbering starts at 001, not 000, so a value like `P0001000T000000` will be incorrectly accepted. The old pattern's sub-patterns `0[0-9][1-9]` and `0[1-9][0-9]` properly excluded 000, but the simplified `[0-2][0-9]{2}` in the new pattern allows it. Consider using `(?:00[1-9]|0[1-9][0-9]|[12][0-9]{2}|3[0-5][0-9]|36[0-5])` to keep the hardening while preserving the 001–365 range.</comment>

<file context>
@@ -2,9 +2,10 @@
   "x-links": [ "https://www.iso.org/standard/70907.html" ],
   "type": "string",
-  "pattern": "^P(?:[0-9]{4}|[+-][0-9]{5,})(?:0[0-9][1-9]|0[1-9][0-9]|[12][0-9]{2}|3[0-5][0-9]|36[0-6])T(?:[01][0-9]|2[0-3])(?:[0-5][0-9])(?:[0-5][0-9])$"
+  "pattern": "^P[0-9]{4}(?:[0-2][0-9]{2}|3[0-5][0-9]|36[0-5])T(?:[01][0-9]|2[0-3])(?:[0-5][0-9])(?:[0-5][0-9])$"
 }
</file context>

Suggested change

	"pattern": "^P[0-9]{4}(?:[0-2][0-9]{2}|3[0-5][0-9]|36[0-5])T(?:[01][0-9]|2[0-3])(?:[0-5][0-9])(?:[0-5][0-9])$"
	"pattern": "^P[0-9]{4}(?:00[1-9]|0[1-9][0-9]|[12][0-9]{2}|3[0-5][0-9]|36[0-5])T(?:[01][0-9]|2[0-3])(?:[0-5][0-9])(?:[0-5][0-9])$"

[cubic-dev-ai]

P2: Test asserts :name (U+02D0 MODIFIER LETTER TRIANGULAR COLON) is invalid, but XML Schema 2001 Name production includes U+02D0 in NameStartChar range #xF8-#x2FF, so it should be valid. The schema pattern uses a negative lookahead to exclude it, but that exclusion is not part of the W3C spec.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At test/w3c/xmlschema/2001/name.test.json, line 643:

<comment>Test asserts :name (U+02D0 MODIFIER LETTER TRIANGULAR COLON) is invalid, but XML Schema 2001 Name production includes U+02D0 in NameStartChar range #xF8-#x2FF, so it should be valid. The schema pattern uses a negative lookahead to exclude it, but that exclusion is not part of the W3C spec.</comment>

<file context>
@@ -637,6 +637,11 @@
+    },
+    {
+      "description": "Invalid - extender character cannot start a name",
+      "valid": false,
+      "data": "ːname"
     }
</file context>

Suggested change

	"valid": false,
	"valid": true,

[cubic-dev-ai]

P3: Duplicate test case: "Valid - leap day in a century leap year" (2000-02-29) is already covered by the existing test "Valid - 29 February 2000 (leap year)" at line 55. Same input and expected result, different descriptions — no new coverage added.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At test/iso/datetime/2019/date/calendar-extended.test.json, line 252:

<comment>Duplicate test case: "Valid - leap day in a century leap year" (2000-02-29) is already covered by the existing test "Valid - 29 February 2000 (leap year)" at line 55. Same input and expected result, different descriptions — no new coverage added.</comment>

<file context>
@@ -240,6 +240,26 @@
+    {
+      "description": "Valid - leap day in a century leap year",
+      "valid": true,
+      "data": "2000-02-29"
+    },
+    {
</file context>

[cubic-dev-ai]

P3: This description narrows anyURI to a URI reference, but XML Schema defines anyURI as an IRI reference. Updating the wording to IRI avoids implying internationalized references are out of scope.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At schemas/2020-12/w3c/xmlschema/2001/any-uri.json, line 4:

<comment>This description narrows `anyURI` to a URI reference, but XML Schema defines `anyURI` as an IRI reference. Updating the wording to IRI avoids implying internationalized references are out of scope.</comment>

<file context>
@@ -1,7 +1,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "title": "W3C XML Schema anyURI",
-  "description": "The anyURI datatype represents an Internationalized Resource Identifier (IRI) reference as defined in RFC 3987, either absolute or relative (§3.2.17)",
+  "description": "The anyURI datatype represents a Uniform Resource Identifier reference (§3.2.17)",
   "$comment": "The anyURI lexical space is laxer than RFC 3986, as any XML character sequence can be escaped into a URI",
   "examples": [
</file context>

Suggested change

	"description": "The anyURI datatype represents a Uniform Resource Identifier reference (§3.2.17)",
	"description": "The anyURI datatype represents an Internationalized Resource Identifier (IRI) reference, either absolute or relative (§3.2.17)",