Skip to content

v1.1.1 — Upstream tracking: rules everywhere

Choose a tag to compare

@pwin pwin released this 14 Aug 19:29
· 33 commits to main since this release

All three toolchains moved, and two things this manual said one edition ago are now the opposite of true. Re-verified by running them.

📄 SemOps-Manual-v1.1.1-A4.pdf — 89 pages, A4.

The WebAssembly build now runs rules

Chapter 11 said flatly that it could not, and that on one shapes graph it returned conforms = true where the native CLI errored — "this is fine" against "I could not check this". Both fixed:

  • Verified against the rebuilt 0.1.9 package: inference="rules" fires the rule and validates the derived data, and an unrecognised mode errors rather than falling back silently to "none".
  • The engine's differential harness reports 0 disagreements across all 473 documents of the W3C corpus, where it previously reported one.
  • sh:declare without sh:prefixes now resolves, and rule compile errors are held on the rule rather than failing the whole shapes graph for callers who never asked for rules.

0.1.9 also fixes $this not being substituted into CONSTRUCT-based rules — a SPARQL rule ran for every node in the graph rather than for its focus node. If you wrote SPARQL rules against an earlier build, re-run them.

What remains is a choice, not a limitation: the VS Code extension bundles the rules-capable engine and asks for inference: "none" deliberately, so rules do not fire in the editor and its report answers a different question from CI's.

The extension swapped its SHACL engine

It replaced its JavaScript implementation with shacl-wasm-node — the same Rust engine the CLI uses natively. On its own workload: 71,237 ms → 324 ms, identical findings, and two shape files that had been crashing outright now run, so DAT-001 and EFF-002 could not fire through the SHACL path at all before.

That makes the manual's "one registry, two runtimes" argument stronger than it was: the rule that fails your build is no longer merely the same data as the rule that underlined the problem in your editor — it is the same engine evaluating it.

Still not on the Marketplace (checked: 404), so the install instructions stand.

What did not change

Re-ran the four --engine modes: unchanged at 4/5/6/6 with LOG-001 still double-reported, so Chapter 7's table needed no correction. STR-007 still drifts — five runs gave 289–298 — so Chapters 9 and 14 stand as written. Conformance is still 418/426, now with zero documents unrunnable.

Notebooks now reachable from the PDF

The print build flattened every relative link, so "notebook 2" reached paper as dead text. Links to files that live only in the repository — notebooks/, tools/, assets/ — now become absolute GitHub URLs in print, while chapter cross-references stay flattened since those point inside the same document.

Notebook 2 gains a Python-binding section, since rules are reachable that way from 0.1.8. All three re-verified against 0.1.9 with zero errors.

Full changelog: v1.1.0...v1.1.1