Skip to content

Conformance Suite Changelog

This page mirrors conformance/CHANGELOG.md in the repository. It tracks the conformance suite (suiteVersion in manifest.json) — fixture additions/removals, case-count changes, errorCode/capability changes, and schema-shape changes. It is versioned independently of the kPointer library; see the library changelog for adapter/API history.

The format follows Keep a Changelog, and the suite adheres to Semantic Versioning.

[0.2.0]

Changed

  • Replaced the dotNotation optional capability with jsPath, covering kPointer's JavaScript access path notation — the static member-access subset of JavaScript used by tools like Vega-Lite's encoding.*.field accessors (dot, quoted-bracket, numeric-bracket, backslash escaping). This is a breaking rename, not an addition: dotNotation is gone, jsPath takes its slot in requiresCapability and in syntax/parsing.json's success-expectation fields. See Capabilities.
  • syntax/parsing.json's dotNotation success field (29 cases, unchanged count) is renamed to jsPath, with values recomputed to the canonical jsPath form (numeric segments now serialize in bracket form, e.g. users.0.name → users[0].name).
  • KP-1004's meaning changed from "dot-notation produced an empty segment" to "JavaScript access path syntactically malformed" — the code is reused, not replaced, since the old meaning is a strict subset of the new one. See Error Codes.
  • algorithm/resolve.schema.json, algorithm/mutate.schema.json, syntax/relative-apply.schema.json, and syntax/relative-compute.schema.json still enumerated the retired dotNotation value for requiresCapability, missed by the rename above. Corrected to jsPath in all four. No fixture in these files currently sets requiresCapability, so this is a schema-consistency fix with no effect on existing case data. See Fixture Schemas.

Added

  • syntax/js-access-path.json (27 cases) — a dedicated jsPath corpus sampled from the vega-util splitAccessPath oracle vectors and representative real-world Vega-Lite field-accessor strings, covering dot, single/double-quoted bracket, numeric bracket, mixed dot/bracket paths, backslash-escaped literal ./[/], the root pointer, and grammar-negative controls expecting KP-1004. See Fixture Schemas.

[0.1.0]

Initial published version of the suite.

Added

  • Five fixture files across two categories:
  • syntax/parsing.json (29 cases) — RFC 6901 parsing, fragment, dot-notation, and auto-dispatch encodings, including non-ASCII BMP, astral (surrogate-pair), and combining-mark keys, and an NFC-vs-NFD pair pinning that the two normalization forms are distinct, never-normalized segment strings. See Writing a Workalike.
  • syntax/relative-apply.json (16 cases) — applying a relative pointer string to an absolute pointer.
  • syntax/relative-compute.json (8 cases) — computing the relative pointer string between two absolute pointers.
  • algorithm/resolve.json (24 cases) — resolving an absolute pointer against a typed document, including a non-ASCII/astral struct key and the minimum safe-integer long bound (-9007199254740991), complementing the existing maximum-bound case.
  • algorithm/mutate.json (18 cases) — applying set/remove mutations to a typed document.
  • A generated, out-of-band manifest.json (format 1.0) recording the suite version and, per fixture file, its own version and case count — guards against a runner silently loading fewer files than it should.
  • A single optional capability, dotNotation, gating dot-notation parsing/output cases via the requiresCapability fixture field. See Capabilities.
  • An 18-entry canonical errorCode taxonomy (KP-1001–KP-4005) spanning the parse, relative, resolve, and mutate layers, each case's error expectation optionally naming the specific code a conforming implementation must raise. See Error Codes.
  • A machine-readable error-codes.json registry of that taxonomy (schema: error-codes.schema.json) — code, layer, normative status, and meaning per entry — so a porter can generate an error enum or validate fixtures against known codes without scraping documentation.
  • A JSON Schema for the kpointer CLI's --full-report output, full-report.schema.json, so a tool in another language can validate its own report output — or interoperate with tooling built against the reference report shape — without scraping the CLI docs. See CLI Reference.
  • A typed element system (string/boolean/long/double/null/struct/list) for algorithm-layer fixtures, so JSON's native ambiguities (integer vs. float, null vs. absent) do not leak into the conformance data itself.
  • JSON Schemas for every fixture file and for the manifest envelope itself, each declaring a canonical $id under https://kpointer.commonsware.com/conformance/. See Fixture Schemas.
  • A committed, canonical full-report.example.json at the suite root — a kpointer conformance --full-report run against the real suite — giving a foreign runner a reference report to diff its own output against. Validate any such report with kpointer validate-report <file>; see CLI Reference.
  • LICENSE-CC-BY-4.0.txt at the suite root, carrying the full CC BY 4.0 legal text matching the attribution language in conformance/README.md.