Context
During review of PR #104, CodeRabbit pointed out that validate_closed_descendant_branches can falsely report an ancestor property as orphaned when a closed descendant branch (additionalProperties: false) permits that property via patternProperties instead of explicit properties.
That observation is valid JSON Schema semantics, but a narrow exception in the orphan check would be incomplete: the current OP#12 compatibility checker does not model patternProperties as a first-class part of effective schema compatibility.
Current behavior
gts/src/schema_compat.rs primarily extracts and compares:
properties
required
additionalProperties
allOf composition
It does not generally account for patternProperties when determining whether derived schemas preserve or loosen ancestor constraints.
Problem
A descendant schema may be valid under JSON Schema while being incorrectly rejected by the compatibility checker, for example when an ancestor property such as userId is covered by a descendant branch like:
{
"additionalProperties": false,
"patternProperties": {
"^user": { "type": "string" }
}
}
At the same time, handling only this closed-branch orphan case would create partial semantics: other compatibility questions involving patternProperties would remain undefined or inconsistent.
Desired outcome
Design and implement full patternProperties support for GTS schema compatibility validation, or explicitly document it as unsupported if the spec should not require it yet.
Potential scope:
- Include
patternProperties in the effective schema model where appropriate.
- Decide how
patternProperties interacts with explicit properties and additionalProperties: false in OP#12 compatibility checks.
- Avoid false positives in closed descendant branch validation when an ancestor property is matched by a descendant pattern.
- Decide how conservative the checker should be for regex subset/equivalence questions.
- Add focused unit tests and, if applicable, gts-spec conformance coverage.
Related
PR #104 review comment: #104 (comment)
Context
During review of PR #104, CodeRabbit pointed out that
validate_closed_descendant_branchescan falsely report an ancestor property as orphaned when a closed descendant branch (additionalProperties: false) permits that property viapatternPropertiesinstead of explicitproperties.That observation is valid JSON Schema semantics, but a narrow exception in the orphan check would be incomplete: the current OP#12 compatibility checker does not model
patternPropertiesas a first-class part of effective schema compatibility.Current behavior
gts/src/schema_compat.rsprimarily extracts and compares:propertiesrequiredadditionalPropertiesallOfcompositionIt does not generally account for
patternPropertieswhen determining whether derived schemas preserve or loosen ancestor constraints.Problem
A descendant schema may be valid under JSON Schema while being incorrectly rejected by the compatibility checker, for example when an ancestor property such as
userIdis covered by a descendant branch like:{ "additionalProperties": false, "patternProperties": { "^user": { "type": "string" } } }At the same time, handling only this closed-branch orphan case would create partial semantics: other compatibility questions involving
patternPropertieswould remain undefined or inconsistent.Desired outcome
Design and implement full
patternPropertiessupport for GTS schema compatibility validation, or explicitly document it as unsupported if the spec should not require it yet.Potential scope:
patternPropertiesin the effective schema model where appropriate.patternPropertiesinteracts with explicitpropertiesandadditionalProperties: falsein OP#12 compatibility checks.Related
PR #104 review comment: #104 (comment)