Skip to content

String constraint pattern comparison bug #36

@Irfan-Ullah-cs

Description

@Irfan-Ullah-cs

Bug: False positive subtyping with string constraints (not: enum vs pattern)

Summary

The isSubschema() function incorrectly returns True when comparing schemas with equivalent string constraints, causing false positive subtyping relationships.

Bug Description

When comparing these two schemas:

  • Schema A: {"type": "string", "not": {"enum": [""]}} (strings that are not empty)
  • Schema B: {"type": "string", "pattern": ".+"} (strings matching non-empty pattern)

The function returns True, indicating Schema A is a subtype of Schema B. However, these schemas are logically equivalent (both accept exactly the same set of strings), so this creates an incorrect subtyping relationship.

Steps to Reproduce

Minimal Example

from jsonsubschema.api import isSubschema

# Both schemas accept exactly the same strings (non-empty strings)
schema1 = {"type": "string", "not": {"enum": [""]}}
schema2 = {"type": "string", "pattern": ".+"}

result = isSubschema(schema1, schema2)
print(f"Result: {result}")  # Currently: True, Expected: False (they're equivalent, not subtype)

Real-world Impact Case

schema1 = {
    "type": ["null", "string"],
    "not": {"enum": [""]}
}

schema2 = {
    "anyOf": [
        {"type": "null"},
        {"type": "string", "pattern": ".+"}
    ]
}

result = isSubschema(schema1, schema2)  # Incorrectly returns True

Expected vs Actual Behavior

Expected: Since both schemas accept exactly the same set of valid strings, they should be considered equivalent, not in a subtype relationship. The function should return False.

Actual: isSubschema(schema1, schema2) returns True, creating a false positive subtyping relationship.

Impact

  • Incorrect schema validation results
  • False positive subtyping relationships in semantic type checking
  • Affects reliability of schema comparison operations
  • Users experience unexpected validation behavior

Request

Would you like me to investigate this further and submit a pull request with a fix?

I'm willing to:

  • Create a comprehensive test suite to reproduce the bug
  • Investigate the root cause in the codebase
  • Implement a minimal, conservative fix
  • Ensure all existing tests continue to pass
  • Document the changes properly

Please let me know if you'd like me to work on this, and if you have any preferences for the approach or specific areas of the code I should focus on.


Thank you for maintaining this library! Let me know how I can help resolve this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions