Skip to content

How to Read ISO Specs (Primer) ​

To interpret the clauses, requirements and definitions that pdf-spec-mcp returns, you need a little of the drafting convention shared by all ISO standards. This page is the minimum needed to use the PDF Family well.

1. The standard skeleton ​

Every ISO standard has roughly the same bones.

SectionContentNormative?
1 ScopeWhat the standard applies toNormative
2 Normative referencesOther standards it cites (cited parts rank with the body text)Normative
3 Terms and definitionsDefinitions. Fixes what a term means inside this standardNormative
4… Body (Clauses)The requirements themselvesNormative
Annex A, B, …Annexes. Normativity depends on the (normative) / (informative) labelDepends on label
BibliographyFurther readingInformative

Numbering deepens as 14 (clause) → 14.9 (subclause) → 14.9.4. get_section's section parameter takes these numbers; passing a parent number returns its whole subtree.

2. Normative vs informative ​

Not every sentence in a standard is a requirement. Confusing the two leads to the classic accident of calling something a "spec violation" on the strength of informative text.

  • NOTEs and EXAMPLEs are informative — they contain no requirements (and per the ISO/IEC Directives they must not)
  • Footnotes are informative too
  • Annexes are judged by the (normative) / (informative) label in their title

pdf-spec-mcp preserves this distinction structurally: in get_section output, NOTE / EXAMPLE come back as note elements separated from paragraph (body text), and get_requirements extracts normative sentences only. Never cite a note element as grounds.

3. Requirement levels — shall / should / may / can ​

The ISO/IEC Directives Part 2 defines the auxiliaries strictly.

AuxiliaryMeaningRelation to conformance
shall / shall notRequirement / prohibitionCondition of conformance. Violation = non-conformance
should / should notRecommendation / discouragementNot following it is not non-conformance
mayPermissionImplementer's freedom
can / cannotPossibility / capabilityNot a requirement (and not a permission either)
  • Everyday-English "must" is not used in ISO normative text (it is reserved for external constraints). Requirements are always shall
  • get_requirements' level maps to these five levels (shall / shall not / should / should not / may), and statistics returns counts per level
  • Only shall counts in a conformance argument. Never write up a should violation as a "spec violation"

4. Definitions (Clause 3) override everyday language ​

Terms and definitions is a normative section that fixes what a term means inside that standard. The terms that drift furthest from everyday usage deserve the most care. Important PDF examples:

  • PDF processor (3.49) / PDF reader (3.51) / PDF writer (3.52) — any active agent that writes, reads, updates or otherwise processes a PDF file, software or not. Whether a shall binds the file or the processor depends on the subject of the sentence. ISO 32000-1's conforming reader / conforming writer was replaced by these in ISO 32000-2, so quoting the older wording against a PDF 2.0 clause misnames the subject
  • running text (3.59) — the body of text, as distinct from headings, footnotes, diagrams and callouts. Narrower than everyday "text"
  • object (3.44) — the basic data structure of a PDF file, and exactly these 9 types (array, boolean, dictionary, integer, name, null, real, stream, string). Not "object" in the programming sense
  • deprecated (3.15) — should not be written into a PDF 2.0 document and should be ignored by a PDF processor. Not "removed"

get_definitions returns Clause 3, which holds 71 entries (3.1–3.71) in ISO 32000-2. Many everyday-sounding PDF terms are not there: artifact and annotation, for instance, are defined in the body (§14.8.2.2 "Real content and Artifacts", §12.5 "Annotations"), so get_definitions finds nothing for them and search_spec / get_section is the way in. An empty result means "not in Clause 3", never "not defined". The notes attached to a definition (Note to entry) are supplements, kept separate from the definition text.

5. Watch the subject — a requirement on the file, or on the processor? ​

ISO 32000's shalls point in two directions.

  • "The value shall be …" → a requirement on the PDF file (a validator can check the file)
  • "A PDF reader shall …" (ISO 32000-1: "A conforming reader shall …") → a requirement on the processor (looking at the file cannot decide conformance)

pdf-verify can check only the former. The latter is never grounds for "this PDF violates the spec". When quoting a clause, quote it with its subject (get_requirements' text is verbatim, so it can be quoted as-is).

6. Read table-derived requirements with their context ​

ISO 32000 keeps many of its requirements in tables (e.g. Table 182 — Additional entries specific to text markup annotations). A cell saying "The type of annotation … shall be …" is meaningless without knowing which table and which entry it binds — that same sentence appears in several annotation tables, each binding a different set of subtypes. That is why get_requirements attaches table / key to requirements with source: "table" — quote that context along with the text. The tables themselves come back structured from get_tables.

StandardContentIn corpus?
ISO 32000-1 (2008)PDF 1.7✅ pdf17
ISO 32000-2 (2020)PDF 2.0 (the default reference)✅ iso32000-2
ISO/TS 32001–32005Extension TSs (SHA-3, ECC signatures, AES-GCM, …)✅
ISO 14289-1/-2PDF/UA (accessibility)✅
ISO 19005PDF/A (long-term preservation)❌ Outside the corpus — verdicts belong to veraPDF
ETSI EN 319 142PAdES (long-term signatures)❌ Outside the corpus — structural observation only (T3)

What zero search hits mean (again)

Zero hits from search_spec mean "this corpus cannot answer", NOT "no such requirement exists". PDF/A and PAdES requirements in particular will never appear here. Check coverage.gaps in list_specs.

MIT Licensed