Skip to content

Add the tabular data profile and the schema-declared, schema-examples and schema-compatibility checks - #178

Merged
lefticus merged 8 commits into
cpp-best-practices:mainfrom
leftibot:main
Nov 13, 2026
Merged

lefticus merged 8 commits into
cpp-best-practices:mainfrom
leftibot:main

Conversation

@leftibot

Copy link
Copy Markdown
Contributor

The schema practices (#85, #86, #87, #88) and the last row of #92: four changes, reviewed and merged one by one as a stack on leftibot/project_validator (its PRs #63 to #66), brought here as one. Each landed with every gate green: the full suite, 99% branch coverage, ruff, mypy, lizard, jscpd and the strict self-check.

The profile

Tabular data (#92): Frictionless Data Packages, a format (Data Package) recognised by intent: a datapackage.json or .yaml, a tableschema.json, or a JSON or YAML file whose $schema or profile names a Data Package profile; a CSV alone makes nothing. schema-validation: frictionless validate (and the frictionlessdata/frictionless-ci action), goodtables, csvlint with a schema. A dvc.yaml alone shows data versioning, not a schema to validate against, and large-files already honours DVC, so it recognises nothing; the issue listed it, and the docs page says why not.

The checks

Check Kind Passes when Otherwise
schema-declared facts (facts/declaration.py: a Declares per format, SchemaDeclaration facts read at extraction) every schema declares its dialect and identifier: $schema and $id; an openapi/asyncapi version and info.version; an XSD's targetNamespace; a .proto file's syntax and package; a descriptor's profile and name fails, listing what each leaves out; a superseded dialect (a JSON Schema draft before 2019-09, Swagger 2.0) warns; a test suite's schemas are reported, not judged
schema-examples tools (aspect examples) CI checks the schemas' examples: ajv test --valid/--invalid, a validator run on an examples directory (check-jsonschema, jv, xmllint, jing), a linter whose rules validate a description's examples (spectral, redocly, vacuum), contract tests (schemathesis, dredd) warns
schema-compatibility tools (aspect compatibility) CI checks the schemas for breaking changes against the main branch or a registry: json-schema-diff, oasdiff breaking (and its action), openapi-diff --fail-on-incompatible, buf breaking (and buf-action) warns

A validator that also checks examples or breaking changes is one tool (combined), as the API linters already were. Formats no tool serves for a practice are not asked.

What else moved

  • The content probes of JSON Schema and Data Package read a top-level key only (^(?:\{\s*)?\s{0,4}"$schema"): a document quoting a schema is no schema. This validator's own facts snapshots, which now record declared $schema values, had made the repository a JSON Schema project in the strict self-check.
  • The well-configured XML fixtures gain a targetNamespace their documents, stylesheet (xpath-default-namespace) and XSpec follow; the Data fixture's XSD now describes the document beside it (its item had attributes the schema did not allow).
  • The JSON Schema, XML schemas, Data and OpenAPI fixtures gain examples and the CI steps that check them and diff the schemas; the bare JSON Schema and Data Package fixtures lose their identifiers.
  • README rows for the three checks, each profile's page, the architecture's aspect list and Declares, history item 13.

What the issues still list beyond this: #86's xsi:schemaLocation on documents; #92's SQL migration-safety check and the later large-files note (already honoured). The user decides what to close.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

leftibot and others added 8 commits November 12, 2026 21:26
Frictionless Data Packages and the tables they describe: a format, Data
Package, recognised by intent (a datapackage.json or .yaml, a
tableschema.json, or a JSON or YAML file whose $schema or profile names
a Data Package profile; a CSV alone makes nothing). The descriptors stay
JSON or YAML, so data-wellformed covers them. What is asked is
schema-validation: frictionless validate (and the frictionless-ci
action, once frictionlessdata/repository), goodtables, csvlint with a
schema. A dvc.yaml alone shows data versioning, not a schema to validate
against, and large-files already honours DVC, so it recognises nothing
here.

Part of cpp-best-practices#92.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
Every schema declares what it is: its dialect, so that it is read as its
author meant, and its identifier, so that it can be referred to. A
format's profile defines a Declares (facts/declaration.py): which files
are its schemas and what each declares; every such schema of the
project's formats is a SchemaDeclaration fact read at extraction, and
the question and policy judge them per format in each unit. What a
schema leaves out fails, listed; a superseded dialect warns; a test
suite's schemas are reported, not judged.

JSON Schema: $schema and $id (a draft older than 2019-09 warns).
OpenAPI and AsyncAPI: the specification version and info.version
(Swagger 2.0 warns). XML Schema: an XSD's targetNamespace. Protobuf:
syntax (or edition) and package. Data Package: a package's or
resource's profile and name.

The content probes of JSON Schema and Data Package now read a top-level
key only: a schema quoted inside another document (this validator's own
facts snapshots) is no schema. The well-configured XML fixtures gain a
targetNamespace their documents, stylesheet and XSpec follow, and the
Data fixture's XSD now describes the document beside it.

Part of cpp-best-practices#85, cpp-best-practices#86, cpp-best-practices#87.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
CI checks the examples that come with each format's schemas: valid ones
that must pass and invalid ones that must fail. A tool-based check over
a new aspect of facts/schema.py, examples, with an advised policy: none
warns, since examples are a schema's tests and a schema may do without.

JSON Schema: ajv test --valid and --invalid, or a validator run on an
examples directory (check-jsonschema, ajv validate, the jsonschema CLI,
jv). OpenAPI and AsyncAPI: spectral, redocly and vacuum, whose rules
validate the examples, or contract tests with schemathesis or dredd.
XML Schema: xmllint with a schema, or jing, run on an examples
directory. A validator that also checks examples is one tool. The JSON
Schema, XML schemas and Data fixtures gain examples and the steps that
check them.

Part of cpp-best-practices#85, cpp-best-practices#86, cpp-best-practices#87.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
CI checks each format's schemas for breaking changes against what was
published before: the main branch's copy, or a registry. A tool-based
check over a third aspect of facts/schema.py, compatibility, with an
advised policy: none warns, since a schema whose consumers are all in
the repository may change freely.

JSON Schema: json-schema-diff against the main branch's copy. OpenAPI:
oasdiff breaking, its action (oasdiff/oasdiff-action/breaking) and
openapi-diff with --fail-on-incompatible. Protobuf: buf breaking, which
buf-action already ran. AsyncAPI is not asked (its CLI's diff does not
fail on breaking changes); Optic is archived. The JSON Schema, Data and
OpenAPI fixtures gain the steps. The history gains the schema stack as
its thirteenth step.

Part of cpp-best-practices#85, cpp-best-practices#86, cpp-best-practices#87, cpp-best-practices#88, cpp-best-practices#92.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
Add the schema-compatibility check
Add the tabular data profile
@lefticus
lefticus merged commit 3fc5038 into cpp-best-practices:main Nov 13, 2026
18 checks passed
@codecov

codecov Bot commented Nov 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.77%. Comparing base (28bdbbc) to head (37cb4bb).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff            @@
##             main     #178    +/-   ##
========================================
  Coverage   99.76%   99.77%            
========================================
  Files         251      258     +7     
  Lines       13276    13560   +284     
  Branches     1475     1495    +20     
========================================
+ Hits        13245    13529   +284     
  Misses         31       31            

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants