alexmandClaude
76d76353d9
- Rename manuspec to paperspec everywhere outside pixi.toml: prose, the tools, provenance tool names and the fixture key derivations, so every fixture and vector is rebuilt. - Move the namespace addresses under the site, mirroring the repository: schema $id https://paperspec.scient.ing/schemas/<file>, the JSON-LD context https://paperspec.scient.ing/context/scienting-1.jsonld, and term IRIs https://paperspec.scient.ing/vocab#<term>. Format identifiers (scienting-*) and URNs (urn:scienting:) are unchanged. - tools/site.py (standard library only) builds _site/: every file of the repository at its own path, each Markdown file rendered as a page with sidebar navigation, heading anchors matching the forge's, folder listings, a vocabulary page for the context's IRIs, a heading search and a 404 page; light and dark themes. - check.py builds the site and checks that every Markdown file has a page, every internal link and fragment resolves, no Markdown is left unrendered, and every $id, the context address and the vocabulary IRIs are files of the site. - deploy/: a Caddyfile with the media types and CORS the data needs, and a guide; .gitea/workflows/site.yml builds on main and publishes with rsync when the SITE_* secrets are set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
34 lines
2.4 KiB
Markdown
34 lines
2.4 KiB
Markdown
# Guides
|
|
|
|
These guides explain paperspec to someone meeting it for the first time.
|
|
They serve three readers: a newcomer who has not seen the problem before, an implementer who will write a reader, writer, converter or checker, and an expert who knows the neighboring standards.
|
|
The [specification](../spec/README.md) says exactly what each format is.
|
|
The guides say what each format is for, with examples drawn from the fixtures.
|
|
|
|
| Guide | For |
|
|
| --- | --- |
|
|
| [Overview](overview.md) | What paperspec is, who it serves, and how its parts fit together. |
|
|
| [Concepts](concepts.md) | The ideas behind the formats, one at a time, each with a real example. |
|
|
| [Walkthrough](walkthrough.md) | One paper, from a flawed first reading to a corrected, reviewed and signed document. |
|
|
| [Examples](examples.md) | Things to run: checking hashes by hand, reading a package with a few lines of Python, querying a database. |
|
|
| [Rationale](rationale.md) | Why the formats look the way they do, and the questions they leave open. |
|
|
| [Comparison](comparison.md) | How paperspec compares with JATS, TEI, W3C Web Annotation and other schemas. |
|
|
| [*FAQ*](faq.md) | Short answers to the questions people ask first. |
|
|
| [Glossary](glossary.md) | Every term, in a sentence. |
|
|
|
|
## Reading orders
|
|
|
|
**Newcomer.** Spend a first afternoon on the overview, then the walkthrough with the fixture open beside it, then the examples.
|
|
Read the concepts when a term in the walkthrough needs more than the glossary gives.
|
|
|
|
**Implementer.** Start with the [specification's reading paths](../spec/README.md#reading-paths), which list the chapters to read for a reader, a converter, a store and a validator.
|
|
Chapters 0, 1, 3, 4 and 5 are needed for any of them.
|
|
Next, run the section "Test your implementation against a vector" in the examples.
|
|
Check your work against the [vectors](../vectors/README.md) and the [fixtures](../fixtures/README.md).
|
|
Chapter 22 of the specification defines conformance.
|
|
|
|
**Expert.** Read the overview for scope and for what paperspec is not, then the comparison for how it differs from existing standards.
|
|
After that, read the rationale for the reason behind each rule and the questions it leaves open.
|
|
It ends with a list of limits.
|
|
Section 0.4 of the specification and [registry/formats.json](../registry/formats.json) give the status of each format: the version is 0.1.0, and each format is `candidate` or `provisional`.
|