Files
paperspec/registry/README.md
T
alexmandClaude 607062056f feat!: pin Python 3.14 and Unicode 16.0, and make the tools commands
Python and Unicode
- requires-python is >=3.14,<3.15: 3.14 is the only Python with the
  Unicode 16.0 data the specification pins (3.13 has 15.1, 3.15 has 17.0).
- `import paperspec` raises ImportError unless unicodedata reports
  paperspec.UNICODE_VERSION (16.0.0), so a source checkout or an install
  that bypasses requires-python cannot compute values on other data.

Commands
- tools/{check,build,validate,load,stress,site}.py move with history to
  src/paperspec/cli/ and install as paperspec-check, -build, -validate,
  -load, -stress and -site; each also runs as `python -m paperspec.cli.X`.
- paperspec.cli.require() exits with "install paperspec[tools]" when
  cryptography or jsonschema is missing; paperspec.cli.checkout() finds
  the repository the check, build, stress and site commands work on (the
  editable install's own checkout, else the one around the current
  folder) and exits with a message outside one. tools/__init__.py is gone.
- validate and load read the schemas and SQL through the new
  paperspec.resources.path(), which finds them in a wheel and in an
  editable install alike, so they work anywhere the package is installed.
- check runs the rebuild as `python -m paperspec.cli.build`.
- build still writes the provenance tool label "paperspec tools/build.py":
  it is part of every hashed and signed fixture.
- pixi tasks and the check workflow run the commands; tools/README.md
  documents them, and the other docs name the commands instead of paths.

License
- LICENSE.md gives `src/` Apache-2.0 alongside `tools/`. Since the
  previous commit moved the code to src/, no row had covered it.

pixi run check passes (run as `python -m paperspec.cli.check` with src/ on
the path, since this environment cannot install the entry points); the
byte-for-byte rebuild matches, so no fixture or vector changed.
pixi.lock still needs `pixi lock`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 09:17:27 -04:00

87 lines
5.8 KiB
Markdown

# Registry
The registry holds lists that tools read at run time.
Each list is a data file, so a reader, writer, converter or checker loads it instead of copying it into code, and a team can change a list without changing a program.
This page is for newcomers, implementers who need the exact behavior, and experts who want the status of each format.
| File | Holds |
| --- | --- |
| `formats.json` | Every format: its identifier, media type (null for the six that have none), schema, status, chapter and a one-line description. |
| `rules.json` | Every validation rule ID, with what it means and the chapter that defines it. |
| `stamps/scienting-stamps-1.json` | The published rules that recognize the download stamps publishers add to PDFs (see Adding stamp rules), so page fingerprints ignore them. |
| `stages/scienting-stages-default.json` | The rights each processing stage needs, as a default a team may replace. |
## Format status
Each entry in `formats.json` has a `status`.
A `candidate` format is complete, with vectors and fixtures, and ready to implement.
It changes only with a recorded reason and a new or changed vector.
A `provisional` format is complete and expected to change as implementations gain experience, so it may change more freely.
At version 0.1.0, 19 of the 32 formats are `candidate` and 13 are `provisional`.
The third defined value, `reserved`, is unused.
The values are defined in [Chapter 0, section 0.4](../spec/00-introduction.md#04-status), and the stability rules in [Chapter 22, section 22.5](../spec/22-conformance.md#225-stability).
## Registering the media types
The `application/vnd.scienting.*` media types are vendor-tree types, which IANA registers on request without a standards document (RFC 6838 §3.2).
Register each type the formats serve over the web before the first release that other tools read: the zipped package, the anchor, the receipt and the layer first.
Until then the types are unregistered and work as they are; a registration changes no byte of any file.
The JSON-LD context is `application/ld+json` and a checkpoint is `text/plain`, both already registered.
## Rule IDs
A validator checks a package and reports each failure as `path:line: rule: message`, for example:
```text
nodes.jsonl:6: doc.hash.node-hash: node_hash does not recompute
```
A `node_hash` is a hash (a fixed-length value computed from content, so any change to the content changes it) stored with each node of a document.
The line above is the failure that `fixtures/invalid/hash-mismatch/` is built to cause: its sixth node record carries a `node_hash` of all zeros.
A rule's meaning never changes, and a retired rule's ID is never reused, so tools and people can rely on the IDs.
A tool can match on the `rule` field, whose meaning is looked up in `rules.json`, and treat the message as text for people.
[Chapter 22, section 22.4](../spec/22-conformance.md#224-rules) lists the ID prefixes.
Each directory in `fixtures/invalid/` has an `expect.json` that names the rule it breaks.
The reference checker (`paperspec-check`) fails if that rule is not in `rules.json`.
## Adding stamp rules
Many publishers add a line to each PDF they serve, naming the institution and the time of download.
This page calls that line a stamp.
Two downloads of one paper then differ, so a hash of the file cannot match them.
A page fingerprint is a hash of a page's size, its text and its images.
It is computed after removing every line that a stamp rule matches ([Chapter 7, section 7.1](../spec/07-geometry.md#71-page-fingerprints)).
The vectors in `vectors/fingerprints.jsonl` show this: `acs-download-1` and `acs-download-2` differ in the institution and the time on their stamp lines and have the same fingerprint.
Suppose two downloads of one paper differ only in a stamp line that no published rule recognizes.
Record a rule in a file of your own, marked as learned:
```json
{"format": "scienting-stamps/1", "id": "smithlab-learned", "learned": true,
"rules": [{"id": "licensed-to", "pattern": "^This copy is licensed to .+", "where": "margin", "margin": 36}]}
```
Normalized text is the line after Unicode Normalization Form C, with each run of whitespace replaced by one space and the ends trimmed ([Chapter 1, section 1.4](../spec/01-conventions.md#14-text-normalization-for-hashing)).
A rule has an `id`, a `pattern`, and a `where` that is `any` or `margin`.
A `margin` rule matches only lines whose box lies wholly within `margin` points of one page edge (36 when the rule gives none).
Patterns use only syntax that ECMAScript and Python read alike, and match a line's normalized text, with the ASCII letters A to Z compared without case.
The allowed syntax is literals, `.`, `*`, `+`, `?`, `^`, `$`, classes and escaped punctuation.
A page record in `pages.jsonl` lists, in `stamps_removed`, the IDs of the rules that removed lines.
A rule that is too broad hides a real difference between two pages.
A stamp that no rule recognizes splits one edition into two ([Chapter 7, section 7.2](../spec/07-geometry.md#72-stamp-rules)).
## Replacing the stage defaults
A stage is one step of processing, such as conversion or indexing.
Each stage needs certain rights, such as the right to mine text, and a stage runs only when the rights record of the paper allows them.
The stage requirements are configuration, not code, because what a team may do depends on how it holds each paper.
A team copies `scienting-stages-default.json`, adjusts it with its counsel and points its project's settings at the copy.
The file itself calls its contents "proposed defaults from the design, for counsel to set".
In a project, the `settings.stages` field holds the `id` of the stage file in use ([Chapter 20](../spec/20-projects.md)), so a team's copy needs an `id` of its own.
The project format is `provisional`.
[Chapter 14](../spec/14-rights.md) explains how stages are checked.