The first stable release. Ninety-two normative statements, each with a permanent identifier.
What 1.0 commits to
An identifier is never reused, never silently repointed at a different requirement, and never deleted: a withdrawn requirement is marked deprecated and stays in the catalogue. Each statement's text is hashed, so a reword that changes what it demands cannot pass CI unnoticed. A 1.x release may add requirements, tighten prose that was ambiguous and correct defects. It does not remove an identifier or change what an existing one means.
The catalogue is 63 document rules, 28 implementation rules and 1 advisory, published at /latest/rules/ and as meta/oold-rules.json.
What it does not commit to: informative sections carry no obligations, and there is no conformance programme. The catalogue marks which statements bind an implementation; the gap between those and what any implementation does is real, and listed below.
Since rc.4
Four new rules, each resolving a defect that would have frozen at the tag:
OOLD-EXT-5ea6- a key aliasing a JSON-LD keyword is never reference-valued, whatever reference signals it carries. rc.4'sOOLD-EXT-6d10andOOLD-EXT-05d3were jointly unsatisfiable forThing.schema.json, whoseidis aliased to@idand carriesformat: iri, and for everything inheriting it. Both implementations already applied this precedence; only the specification did not state it.OOLD-EXT-9ee8- a tool resolvingx-oold-refterminates on a cyclic reference graph. Split out ofOOLD-EXT-6007, which was cataloguedSHOULDwhile its operative clause was aMUST.OOLD-EXT-3ea9-x-oold-rangeandx-oold-refname a URI reference resolved against the base URI, not a compact IRI (#178).OOLD-INS-78df- the schema-resolution order ($schema, then the@contextURL, then an inline type), previously stated in the indicative and absent from the catalogue.
Also corrected: five rules in section 7 stated MUST or SHOULD with no authored level; OOLD-CMP-b926 now scopes to $ref targets that are themselves OO-LD schemas, since a $ref to a plain JSON Schema carries no terms and reflects nothing; section 9 still described required as $id alone against the shipped ["$id", "@context"]; section 8's examples predated the root @context requirement.
Two extractor defects had corrupted hashed text. The emphasis stripper ran over code spans, so OOLD-EXT-2b61's catalogued regex had lost both quantifiers and disagreed with the rendered page. List absorption truncated OOLD-EXT-c77a mid-enumeration, so it promised three forms and listed one, reading as a prohibition on the other two.
Upgrading
/latest/guide/upgrading/ covers everything since rc.3. The breaking changes are rc.4's: a root @context is required, x-oold-reverse-default-properties is withdrawn, and seven indicative statements became normative. Nineteen rules were added across rc.4 and rc.5; the guide lists only those that can make something that worked stop working.
Media types
application/oold-schema+json and application/oold-schema-instance+json are specified and not registered with IANA (#13). Section 11 says so rather than implying otherwise.
Known gaps
- 19 of 47 machine-checkable rules have no fixture behind them.
make validatereports the list rather than passing silently. - 28 rules bind an implementation and nothing measures them. The conformance programme is planned work, not part of this release.
x-oold-reverse-properties(OOLD-EXT-eeda) has no implementation inoold-python(#165).
The reference implementation is oold 2.1.0. It vendors this meta-schema under 1.0.0-rc.5; the files are byte-identical, and a release vendoring it under 1.0.0 follows.
Earlier notes: v1.0.0-rc.4.