divejson 0.26.0__tar.gz → 0.28.0__tar.gz

{divejson-0.26.0 → divejson-0.28.0}/CHANGELOG.md

@@ -7,6 +7,31 @@ this file is about the package, whose version moves independently.
 
 ## Unreleased
 
+## 0.28.0
+
+- **The gear types `backplate` and `wing`.** §6.12 of
+  [the specification](https://github.com/divejson/divejson/blob/main/spec/divejson.md)
+  names a backplate-and-wing rig's parts apart, while a `bcd` stays the general word for a
+  buoyancy compensator, so `divejson validate` accepts both. The UDDF writer writes a wing
+  as a `<buoyancycontroldevice>`, which reads back as `bcd`, and a backplate as a
+  `<variouspieces>`, which reads back as `other`; each is reported as a type that did not
+  survive. The reader does not change.
+
+## 0.27.0
+
+- **Breaking: a species' registry entries are its `external_ids`, and `aphia_id` and
+  `wikidata_qid` are removed.** §6.11 of
+  [the specification](https://github.com/divejson/divejson/blob/main/spec/divejson.md)
+  gives a species the list a dive site carries, so one document spells one registry one way,
+  and the format names a third registry, `worms`, whose identifier is the AphiaID's digits.
+  A species carries at most one `worms` entry and is identified by a name or by one entry
+  under any registry. `divejson validate` refuses a species carrying either old member as an
+  undefined one, and one registry entry listed twice on a species as it does on a site;
+  a `worms` entry on any record, a site's included, is held to the digits where it was
+  carried as written before. Moving `"aphia_id": 127160` to
+  `"external_ids": [{"registry": "worms", "identifier": "127160"}]` is the whole fix, and a
+  `wikidata_qid` becomes a `wikidata` entry the same way.
+
 ## 0.26.0
 
 - **A cylinder links the gear item it is, the gear item carries the vessel's facts, and a

{divejson-0.26.0 → divejson-0.28.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: divejson
-Version: 0.26.0
+Version: 0.28.0
 Summary: Validator, converters and conformance runner for DiveJSON, an open dive-log interchange format
 Project-URL: Homepage, https://divejson.org
 Project-URL: Repository, https://github.com/divejson/divejson-py

divejson-0.28.0/SPEC_REF

@@ -0,0 +1 @@
+b690062adafa2b8bf29a188bc5f41769bd9902b4

{divejson-0.26.0 → divejson-0.28.0}/divejson/__init__.py

@@ -22,7 +22,7 @@ specification commit named in the repository's ``SPEC_REF``, so that an installe
 resolves its own schema and needs no checkout of anything.
 """
 
-__version__ = "0.26.0"
+__version__ = "0.28.0"
 
 SPEC_VERSION = "1.0"
 

{divejson-0.26.0 → divejson-0.28.0}/divejson/uddf_write.py

@@ -124,13 +124,16 @@ GENERATOR_TYPE = "converter"
 
 _INDENT = "  "
 
-# Where each of §6.12's gear types lands in `equipmentType`. Every type UDDF's own
-# vocabulary does not name goes to `<variouspieces>`, which is UDDF's catch-all and which
-# the reader maps back to `other` — the same translation the reader makes in the other
-# direction for `<lead>`. The reference writer sends a line cutter and a
-# pair of shears to `<knife>` instead, on the grounds that they are cutting tools; this one
-# does not, because `<knife>` asserts a knife where `<variouspieces>` asserts nothing, and
-# a converter's job is to lose the type honestly rather than to substitute a near one.
+# Where each of §6.12's gear types lands in `equipmentType`. A type goes to the element
+# for what it is, and one UDDF's own vocabulary has no element for goes to
+# `<variouspieces>`, which is UDDF's catch-all and which the reader maps back to `other` —
+# the same translation the reader makes in the other direction for `<lead>`. A wing is a
+# buoyancy control device, so it goes to `<buoyancycontroldevice>` and reads back as the
+# general `bcd`. The reference writer sends a line cutter and a pair of shears to `<knife>`
+# instead, on the grounds that they are cutting tools; this one does not, because `<knife>`
+# asserts a knife where `<variouspieces>` asserts nothing, and a converter's job is to lose
+# the type honestly rather than to substitute a near one. An element naming the broader
+# kind, as the BCD's does for a wing, is not a near one: it says nothing false.
 _EQUIPMENT_ELEMENT: dict[str, str] = {
     "mask": "mask",
     "snorkel": "variouspieces",
@@ -142,6 +145,8 @@ _EQUIPMENT_ELEMENT: dict[str, str] = {
     "gloves": "gloves",
     "boots": "boots",
     "bcd": "buoyancycontroldevice",
+    "backplate": "variouspieces",
+    "wing": "buoyancycontroldevice",
     "regulator": "regulator",
     "rebreather": "rebreather",
     "computer": "divecomputer",

{divejson-0.26.0 → divejson-0.28.0}/divejson/validate.py

@@ -4,9 +4,10 @@ Two passes, mirroring §3 of the specification: the JSON Schema (types, required
 enums, ranges, lengths, and the structural rules like Position objects), then the
 semantic requirements the schema cannot express — identifier uniqueness, referential
 closure, a record listed once in a list of references and a registry entry once in a site's
-external ids, a tag listed once on a dive or a site and a site's names each once when trimmed
-and case-folded, cross-member arithmetic, profile-series integrity and span, what a
-recording carries, the offset requirement on ``exported_at``, and the gradient-factor order.
+or a species' external ids, a tag listed once on a dive or a site and a site's names each
+once when trimmed and case-folded, cross-member arithmetic, profile-series integrity and
+span, what a recording carries, the offset requirement on ``exported_at``, and the
+gradient-factor order.
 
 §4's member order is a SHOULD, not a requirement on the document: a generic
 re-serialisation commonly sorts an object's members, and a document it produced is as
@@ -345,6 +346,9 @@ def _semantic_issues(doc: dict[str, Any]) -> list[Issue]:
         _check_other_names(site, here, issues)
         _check_external_ids(site, here, issues)
 
+    for index, species in enumerate(collections["species"]):
+        _check_external_ids(species, f"species/{index}", issues)
+
     for index, gear_set in enumerate(collections["gear_sets"]):
         _check_reference_list(
             gear_set, "gear_uuids", known["gear"], "gear", f"gear_sets/{index}", issues
@@ -541,14 +545,14 @@ def _check_other_names(site: dict[str, Any], path: str, issues: list[Issue]) ->
     _check_folded(site.get("other_names"), listed, f"{path}/other_names", "other name", issues)
 
 
-def _check_external_ids(site: dict[str, Any], path: str, issues: list[Issue]) -> None:
-    """No two of a site's external ids naming one registry entry, compared exactly.
+def _check_external_ids(record: dict[str, Any], path: str, issues: list[Issue]) -> None:
+    """No two of a record's external ids naming one registry entry, compared exactly.
 
     The schema cannot say it, for rule 7's reason: an External Id may carry `extensions`, so
     two entries naming one pair are two different objects to `uniqueItems` whenever anything
     beside the pair differs. The pair alone decides.
     """
-    entries = site.get("external_ids")
+    entries = record.get("external_ids")
     if not isinstance(entries, list):
         return
     listed: dict[tuple[str, str], int] = {}

{divejson-0.26.0 → divejson-0.28.0}/docs/uddf-mapping.md

@@ -471,8 +471,10 @@ service performed — which is what §6.14 and §6.15 are.
 The last row is translation rather than invention: `<variouspieces>` is UDDF's own
 catch-all, a weight belt's quantity is the dive's `weight` (§6.2), a watch is a computer or
 jewellery, and a compressor is not kit carried on a dive — so none of the three earns a
-value of its own. UDDF has no element for a `transmitter`, which is written as
-`<variouspieces>` ([`uddf-writing.md`](uddf-writing.md)) and so comes back as `other`. `<equipmentconfiguration>` is skipped — it describes how the pieces are rigged
+value of its own. UDDF has no element for a `transmitter` or a `backplate`, which are
+written as `<variouspieces>` ([`uddf-writing.md`](uddf-writing.md)) and so come back as
+`other`; a `wing` is written as the buoyancy control device it is, and so comes back as
+`bcd`. `<equipmentconfiguration>` is skipped — it describes how the pieces are rigged
 together, not a piece.
 
 **`<divecomputer>` is one element read two ways.** It is a piece of kit the diver owns, and

{divejson-0.26.0 → divejson-0.28.0}/docs/uddf-writing.md

@@ -172,20 +172,24 @@ reaches a document.
 An insurance's `number` and the diver's `emergency_contacts` and `portrait_file` have no
 element, and each is reported — *What is never written* has why.
 
-Gear types land in `equipmentType`'s elements. A type UDDF's own vocabulary does not name
-goes to **`<variouspieces>`**, its catch-all, which a reader maps back to `other`; that is
-the same translation a reader makes for `<lead>` in the other direction, and it is
-reported, since the type did not survive.
+Gear types land in `equipmentType`'s elements. A type UDDF names only by its broader kind
+goes to that kind's element: a `wing` is a buoyancy control device, so it is written as
+**`<buoyancycontroldevice>`**, which a reader maps back to `bcd`, §6.12's general word for
+one. A type UDDF's own vocabulary does not name at all goes to **`<variouspieces>`**, its
+catch-all, which a reader maps back to `other`; that is the same translation a reader makes
+for `<lead>` in the other direction. Either way the type did not survive, and it is
+reported.
 
 | `gear.type` | UDDF element | comes back as |
 | --- | --- | --- |
 | `mask`, `fins`, `gloves`, `boots`, `compass`, `knife`, `light`, `regulator`, `rebreather`, `scooter` | the same name | itself |
 | `bcd` | `buoyancycontroldevice` | itself |
+| `wing` | `buoyancycontroldevice` | `bcd` |
 | `computer` | `divecomputer` | itself |
 | `cylinder` | `tank` | itself |
 | `wetsuit`, `drysuit` | `suit`, with `<suittype>` | itself |
 | `other` | `variouspieces` | itself |
-| `snorkel`, `vest`, `hood`, `smb`, `mirror`, `whistle`, `reel`, `camera`, `line_cutter`, `shears`, `transmitter` | `variouspieces` | `other` |
+| `snorkel`, `vest`, `hood`, `smb`, `mirror`, `whistle`, `reel`, `camera`, `line_cutter`, `shears`, `transmitter`, `backplate` | `variouspieces` | `other` |
 
 `camera` is in the last row for a schema reason rather than a vocabulary one: `cameraType`
 extends `ID_TYPE` rather than `namedType`, so a `<camera>` has no `<name>` at all and could
@@ -209,7 +213,9 @@ written as anything but a `<tank>` the two are reported, as `working_pressure` a
 the grounds that they are cutting tools and that scattering a diver's cutting tools into the
 catch-all beside the SMB reads worse. A converter does not, because `<knife>` asserts a
 knife where `<variouspieces>` asserts nothing — losing a type honestly beats substituting a
-near one, and the report is what makes the loss visible either way.
+near one, and the report is what makes the loss visible either way. An element naming the
+type's broader kind is not a near one: `<buoyancycontroldevice>` says nothing of a wing that
+is not true of it, which is why a wing goes there rather than to the catch-all.
 
 **`equipmentType` is an `xs:sequence`, so a logbook's gear comes back grouped by type**
 rather than in the order the document listed it. Nothing is lost by that — every piece keeps

{divejson-0.26.0 → divejson-0.28.0}/fixtures/README.md

@@ -33,7 +33,7 @@ what makes a fixture dropped into this tree impossible to ignore.
 | `minimal.divejson` | The smallest conforming document: `format`, `version`, `exported_at` — no diver (a source that records nothing about its owner omits the member), no collections (absent ≡ empty). |
 | `demo-logbook.divejson` | A real export of the reference writer's demo account (all names are seeded demo data; pulled 2026-09-02, courses-era writer): 8 dives, one carrying a recording with its device, its stored file and a full sampled profile, which is what a dive imported from a computer file looks like — sites, trips, an empty `courses` collection, gear with a service history, certifications, and producer extensions carrying application-specific values. Its device is written by hand: the export predates recordings, and the file it names was read by the `suunto_json` parser, so the device is what that reader takes from such a file. So are the diver's `phone`, `born_on`, `emergency_contacts` and `insurances`, one element in each array, which the export predates as well. Its profile axis is in milliseconds, multiplied by hand from the seconds the export wrote, and its root `extensions` carries, under the writer's producer key, the `profile_axis` marker that writer emits beside a millisecond axis and its own reader keys on — added by hand the same way, a value of the same kind as the `units` its diver carries. Its temperature samples are in hundredths of a degree, multiplied by hand from the tenths the export wrote, and beside the axis marker sits the `profile_temperature_scale` marker of `100` that writer emits with them, added by hand the same way. Its one **contact** is added by hand the same way — Blue Lagoon Divers, which the diver's two PADI cards name, with every member of §6.18 but `extensions` — and referenced from the four hosts the file has: the Tenerife week's three dives, both cards, the service record, whose `performed_by` names the technician beside it, and that trip's part as its accommodation. Its `courses` being empty, the fifth host is `technical-dive.divejson`'s. Its one **person** is added by hand the same way, with every member of §6.20 but `extensions`, a name carrying a non-ASCII letter, and referenced as a `buddy` from the first Tenerife dive and from that trip. Regenerate from a fresh export when the writer changes. |
 | `two-computers.divejson` | Hand-built coverage of §6.4a, and of the half of it no converter can reach: a dive with **two** recordings that both carry a profile — `ssrf/two-computers.ssrf` reaches that much from one file — where the first holds **two** `source_files`, one recording the app exported twice, as JSON beside FIT, each file read by a different parser. Its second recording carries its own `started_at`, 31.33 s after the dive's, so its samples sit on their own axis. Each recording carries its own **readouts** (§6.4a), and they differ — the two answers a dive gets from two computers, which no converted pair reaches: the first carries a surface pressure and both ends of both oxygen clocks, its CNS and OTU ends being the ones the same dive's FIT export states, and the second a surface pressure of its own and nothing else. Its two devices differ in every way §6.4b allows two devices to differ, and the second computer's deepest sample is deeper than the dive's logged `max_depth`, which is the ordinary disagreement between two devices rather than a defect. It has no pair: §6.7's stored-file records are the application's and no reader produces one, which is the point of it. It is also where the two halves of §6.4c the other hand-built file cannot reach live: its first recording runs an RGBM model named in words with a **negative** `conservatism` and no gradient factors, the shape a Suunto states, while its second is in **`gauge`** mode and carries no `deco_model` at all — a computer run as a bottom timer runs no decompression model, and saying so is not the same as saying nothing. Between the two files every member of §6.4c's table and two of §6.4a's five `mode` values are exercised by a document no converter wrote; `freedive` comes from `suunto_xml/freedive.xml`, and `closed_circuit` and `semi_closed` wait for a file, no source in hand stating either. |
-| `technical-dive.divejson` | Hand-built coverage of what the demo corpus lacks: trimix, a sidemount pair (two cylinders, one blend, `usage: "parallel"`, each linked to a vessel of its own), staged deco cylinders, gas-switch events, a ceiling channel with a gap, per-cylinder pressure channels, a `+12:45` UTC offset **and** an offset-less local `started_at` (§5.2's third state), a dive with no recorded time in the water, a third dive whose `started_at` is a **date** — logged by hand with the day and no time of day (§5.2) — and whose one recording carries nothing but the `cns_end` copied off the computer, the readout-only recording §6.4a allows, a common-name-only species, two **sightings** — one carrying a `count` and `notes`, the other neither, seen and not counted (§6.3a) — a first dive carrying a `type`, a `rating`, three `tags`, an `air_temperature`, a `current`, `waves`, `weather`, an `entry_type` of `boat` and that boat's `boat_name` (§6.2) — a trip of three parts — a place with dates, a place with none, and dates with no place — the second of them carrying an antimeridian-crossing bounding box, the corpus's only **dive site whose locality is filled in** — a centre and a box on `location`, beside the site's own pin at a different point, which is the pair §6.10 exists to keep apart — and the same site the corpus's only one carrying the rest of §6.10: two `other_names`, three `external_ids` — one under each registry the format names and one under a registry it does not, carrying `extensions` — a depth range, a `water_type`, an `altitude` of `0` and two `entry_types` and `tags` — an `agency: "other"` certification with `front_file`/`back_file` and an `aida` one, a value from the widening that closed §6.16's vocabulary, a service interval on dives and on hours of diving at once, three courses — a completed `"other"`-agency course linked from a dive and its certification, an unreferenced `"planned"` one with no dates, and one with **no `agency`**, the private-instructor case §6.17 leaves the member out for — a lowercase-`z`, one-digit-fraction `created_at` (both spellings the grammar allows and naive parsers reject), and a `bookmark` 85 s **past** `profile.duration` — the surface-marker case §6.4 blesses, which the pre-2026-09-04 validator rejected, and which also carries a `label` beside a `type`, the pairing §6.6 asks for on any value defined after 1.0. Its recording's device carries **all six** of §6.4b's members, hand-built like the rest of the file. Its diver carries an emergency contact, an insurance with a `number` and a `portrait_file`, the three members of §6.1 UDDF has no element for. It is also the **decompression** fixture: `mode: "open_circuit"` and a Bühlmann `deco_model` with a name and a 30/70 gradient-factor pair, the recording's five readouts, a `salinity` of `en13319` on a dive whose `water_type` is `salt` — the setting and the water being two facts (§6.4a) — and all six of §6.4's readout channels sampled on the depth channel's own times — an `ndl` that runs from the 99-minute display cap down to zero and back, a zero `ndl` at the same second as a `ceiling` (the coexistence §6.4 blesses), a `tts` present only while there is an obligation, a `ppo2` that climbs through three gases, a `cns` whose ends are the recording's own `cns_start` and `cns_end`, and a `surface_gradient_factor` above 100 with the `gradient_factor` beside it far below. Its profile's `extensions` carries a tissue-loading array, which is what §6.4c says tissue state rides until a reader can compute from it. Its one **contact** carries every member of §6.18 and §6.19, `extensions` included, and is referenced from all five hosts: the first dive, the completed course and its card, the service record, whose `performed_by` names the technician beside it, and the first trip part, as where the diver stayed. Its four **people** reach every host §6.20 has and every value of its `role` but `guide`: J. Harbord, carrying every member, `extensions` included under an example producer key, is the completed course's `instructor`, its card's `instructor_uuid` and the first dive's `instructor`; a fellow student is that course's and that dive's `student`, the second dive's `buddy`, the third dive's reference with **no** `role`, and the trip's `buddy` beside a one-word `companion` who never dived; and the private course names its own instructor. Its **gear** is where §6.3's vessel link and §6.12's vessel facts live: each cylinder of the sidemount pair links a 12 L, 232 bar steel of its own, and the Twin 12 manifold carries its own facts — 24 L, 232 bar, steel — and a `dive_time` beside its `dive_count`, linked from no cylinder and listed in no dive's `gear_uuids`, since a twinset beside a sidemount pair on two 12 L supplies would contradict §6.3's rule that an entry is one gas supply; its figures stay the source logbook's. The twinset's schedule carries `interval_hours`, `dive_time_at_start` and `next_due_at_dive_time` beside their count twins and its record `dive_time_at_service`, and one sidemount steel carries a schedule whose **only** interval is `interval_hours`, the arm of §6.14's at-least-one rule nothing else here satisfies alone. |
+| `technical-dive.divejson` | Hand-built coverage of what the demo corpus lacks: trimix, a sidemount pair (two cylinders, one blend, `usage: "parallel"`, each linked to a vessel of its own), staged deco cylinders, gas-switch events, a ceiling channel with a gap, per-cylinder pressure channels, a `+12:45` UTC offset **and** an offset-less local `started_at` (§5.2's third state), a dive with no recorded time in the water, a third dive whose `started_at` is a **date** — logged by hand with the day and no time of day (§5.2) — and whose one recording carries nothing but the `cns_end` copied off the computer, the readout-only recording §6.4a allows, three **species** — the black coral carrying a `worms` and a `wikidata` entry beside its names, two registries on one taxon; a common-name-only one; and one with **no name**, carrying two entries under one registry the format does not name, which is the arm of §6.11's identity rule nothing else here satisfies alone and the several entries of one registry that the one-`worms`-entry bound leaves open to every other — and three **sightings**, one carrying a `count` and `notes` and the other two neither, seen and not counted (§6.3a), the nameless species' beside the carpet shark's on the second dive — a first dive carrying a `type`, a `rating`, three `tags`, an `air_temperature`, a `current`, `waves`, `weather`, an `entry_type` of `boat` and that boat's `boat_name` (§6.2) — a trip of three parts — a place with dates, a place with none, and dates with no place — the second of them carrying an antimeridian-crossing bounding box, the corpus's only **dive site whose locality is filled in** — a centre and a box on `location`, beside the site's own pin at a different point, which is the pair §6.10 exists to keep apart — and the same site the corpus's only one carrying the rest of §6.10: two `other_names`, three `external_ids` — one under `openstreetmap`, one under `wikidata` and one under a registry the format does not name, carrying `extensions` — a depth range, a `water_type`, an `altitude` of `0` and two `entry_types` and `tags` — an `agency: "other"` certification with `front_file`/`back_file` and an `aida` one, a value from the widening that closed §6.16's vocabulary, a service interval on dives and on hours of diving at once, three courses — a completed `"other"`-agency course linked from a dive and its certification, an unreferenced `"planned"` one with no dates, and one with **no `agency`**, the private-instructor case §6.17 leaves the member out for — a lowercase-`z`, one-digit-fraction `created_at` (both spellings the grammar allows and naive parsers reject), and a `bookmark` 85 s **past** `profile.duration` — the surface-marker case §6.4 blesses, which the pre-2026-09-04 validator rejected, and which also carries a `label` beside a `type`, the pairing §6.6 asks for on any value defined after 1.0. Its recording's device carries **all six** of §6.4b's members, hand-built like the rest of the file. Its diver carries an emergency contact, an insurance with a `number` and a `portrait_file`, the three members of §6.1 UDDF has no element for. It is also the **decompression** fixture: `mode: "open_circuit"` and a Bühlmann `deco_model` with a name and a 30/70 gradient-factor pair, the recording's five readouts, a `salinity` of `en13319` on a dive whose `water_type` is `salt` — the setting and the water being two facts (§6.4a) — and all six of §6.4's readout channels sampled on the depth channel's own times — an `ndl` that runs from the 99-minute display cap down to zero and back, a zero `ndl` at the same second as a `ceiling` (the coexistence §6.4 blesses), a `tts` present only while there is an obligation, a `ppo2` that climbs through three gases, a `cns` whose ends are the recording's own `cns_start` and `cns_end`, and a `surface_gradient_factor` above 100 with the `gradient_factor` beside it far below. Its profile's `extensions` carries a tissue-loading array, which is what §6.4c says tissue state rides until a reader can compute from it. Its one **contact** carries every member of §6.18 and §6.19, `extensions` included, and is referenced from all five hosts: the first dive, the completed course and its card, the service record, whose `performed_by` names the technician beside it, and the first trip part, as where the diver stayed. Its four **people** reach every host §6.20 has and every value of its `role` but `guide`: J. Harbord, carrying every member, `extensions` included under an example producer key, is the completed course's `instructor`, its card's `instructor_uuid` and the first dive's `instructor`; a fellow student is that course's and that dive's `student`, the second dive's `buddy`, the third dive's reference with **no** `role`, and the trip's `buddy` beside a one-word `companion` who never dived; and the private course names its own instructor. Its **gear** is where §6.3's vessel link and §6.12's vessel facts live: each cylinder of the sidemount pair links a 12 L, 232 bar steel of its own, and the Twin 12 manifold carries its own facts — 24 L, 232 bar, steel — and a `dive_time` beside its `dive_count`, linked from no cylinder and listed in no dive's `gear_uuids`, since a twinset beside a sidemount pair on two 12 L supplies would contradict §6.3's rule that an entry is one gas supply; its figures stay the source logbook's. The twinset's schedule carries `interval_hours`, `dive_time_at_start` and `next_due_at_dive_time` beside their count twins and its record `dive_time_at_service`, and one sidemount steel carries a schedule whose **only** interval is `interval_hours`, the arm of §6.14's at-least-one rule nothing else here satisfies alone. Its steel `backplate` and doubles `wing` are the corpus's only items of either type, a rig recorded as its parts, and the gear set lists both beside the twinset and the drysuit. |
 
 ## invalid/
 
@@ -128,15 +128,22 @@ validator does not look.
 | `external-id-identifier-empty.divejson` | an empty `identifier`, under a registry the format does not name | §6.10 |
 | `external-id-identifier-too-long.divejson` | an `identifier` of 256 characters, under a registry the format does not name | §6.10 |
 | `external-id-wikidata-form.divejson` | a `wikidata` entry whose `identifier` is the item's URL rather than its `Q` number | §6.10 |
+| `external-id-worms-form.divejson` | a species' `worms` entry whose `identifier` is the record's LSID rather than its AphiaID's digits | §6.10, §6.11 |
 | `external-id-openstreetmap-form.divejson` | an `openstreetmap` entry whose `identifier` is the element's bare number, which names a node, a way or a relation without saying which | §6.10 |
 | `external-ids-repeated.divejson` | a site's `external_ids` carrying one entry twice, byte for byte, which the schema's `uniqueItems` rejects | §6.10 |
 | `external-ids-repeated-with-extensions.divejson` | a site's `external_ids` carrying one `openstreetmap` entry twice, the second with `extensions` — two different objects, which the schema's `uniqueItems` would not catch | §3 rule 7, §6.10 |
+| `species-external-ids-repeated-with-extensions.divejson` | the same defect on a **species'** `external_ids`, one `wikidata` entry twice — a validator walking only sites passes it, and a `worms` entry twice would never reach the rule, the schema refusing a second one | §3 rule 7, §6.11 |
 | `bbox-without-position.divejson` | a `bbox` on a location with no `position` | §6.9 |
 | `location-full-name.divejson` | a dive site's location carrying `full_name` — the retired member | §5.5, §6.9 |
-| `species-no-identity.divejson` | a species with no AphiaID and no name at all | §6.11 |
+| `species-no-identity.divejson` | a species with no registry entry and no name at all | §6.11 |
+| `species-external-ids-empty.divejson` | a species with no name whose only identity is an empty `external_ids`, which satisfies nothing | §6.11 |
+| `species-aphia-id.divejson` | a species carrying `aphia_id` — the retired member, its `worms` entry under its old name | §6.11 |
+| `species-wikidata-qid.divejson` | a species carrying `wikidata_qid` — the retired member, its `wikidata` entry under its old name | §6.11 |
+| `species-two-worms-entries.divejson` | a species carrying two `worms` entries with different identifiers — its record and the synonym that points at it — which the schema's `maxContains` rejects | §6.11 |
 | `gear-volume-not-positive.divejson` | a gear item's `volume` of `0` | §6.12 |
 | `gear-working-pressure-too-high.divejson` | a gear item's `working_pressure` of `351`, past §6.3's pressure ceiling | §6.12 |
 | `gear-material-unknown.divejson` | a gear item's `material` of `"aluminum"`, where the vocabulary spells it as UDDF does | §6.12 |
+| `gear-type-unknown.divejson` | a gear item's `type` of `"harness"`, which the vocabulary does not carry — §6.12 types a plate with its harness `"backplate"` | §6.12 |
 | `gear-dive-time-negative.divejson` | a gear item's `dive_time` of `-1` | §6.12 |
 | `schedule-without-interval.divejson` | a service schedule with none of `interval_months`, `interval_dives` and `interval_hours` | §6.14 |
 | `schedule-interval-hours-not-positive.divejson` | a service schedule's `interval_hours` of `0` | §6.14 |
@@ -319,7 +326,7 @@ reaches.
 | file | written from | what it covers |
 | --- | --- | --- |
 | `opendiving.divejson` | `uddf/opendiving.divejson`, plus a device | The round trip that matters most, and the pair that exercises almost none of the report: this document is itself the *reading* of a UDDF export, so there is nothing in it UDDF cannot hold, and the only finding is the `extensions` exclusion every written file carries. `dive-<uuid>` ids that come back as those uuids, a trip of one part, written back with its dates and with its place in both the `<name>` and the `<geography><location>`, where the source's `<name>` held a label the reading reported, a kit list under `<equipment>` with per-dive `<equipmentused>` links, two cylinders on two gases with their pressure channels, a `<switchmix>` gas switch and a `<setmarker>`. And the **fold**: its dive lists that `computer` gear item, which satisfies the predicate's link leg, and its recording's device and the gear item carry the same serial, so the serial leg fires and the two become one `<divecomputer>` element carrying both halves, with the device's counter on the dive as `<internaldivenumber>`. It is the corpus's only pair that reaches the serial leg. **No pair reaches the link leg refusing** — a `computer` gear item the document carries and one of its own dives does not link — so that branch has no pair either way, and [`docs/uddf-writing.md`](../docs/uddf-writing.md) writes it down rather than leaving it to the first writer to meet one. Its diver's `born_on`, `phone` and insurance are written to `<birthdate>`, `<contact><phone>` and `<diveinsurances>`, which puts a `<contact>` between `<personal>` and `<equipment>` and the insurances after the kit list, the order `personType` fixes. |
-| `technical-dive.divejson` | `valid/technical-dive.divejson` | Everything the first one cannot reach, being hand-built to hold what no UDDF export carries. The `dropped` half of the report: `courses`, `certifications`, `gear_sets` and gear service, which UDDF has no slot for; `species` and the dives' sightings, whose slot a writer could fill only by inventing a class for each; `role` and `usage` on a sidemount pair and its staged deco cylinders; a ceiling channel; a trip part's bounding box, and a dive site's locality entire but for its name — its centre and its box, which is two findings off one record where a part loses one; the gas numbering UDDF cannot record; `shears` landing in `<variouspieces>` and reading back as `other`; a `bookmark` carrying a label, which keeps its type and loses the label; an event with a label and no type, which goes out as a `<setmarker>` carrying the label; the `deco_model`, `tts` and `surface_gradient_factor` its document now carries, each reported `dropped` — the first because UDDF's `<decomodel>` requires a tissue table this format has no member for, the other two because UDDF has no element at all; an empty note, which no UDDF file can spell; a device's `firmware`, for which `equipmentPieceType` has no element; and the diver's `emergency_contacts` and `portrait_file` and an insurance's `number`, which UDDF has no element for either — the insurance itself is written, as a `<diveinsurances>` entry carrying its provider. Its first dive's `type`, `rating`, `air_temperature` and `current` are written — `<apparatus>open-scuba</apparatus>` after the kit, a `<ratingvalue>` of `8`, twice the five-step rating, a Kelvin `<airtemperature>` after the `<datetime>` and `moderate-current` — and its `tags`, `waves`, `weather` and `boat_name` are each reported `dropped`, UDDF having no element for any of them; so is its `entry_type` of `boat`, since UDDF's boats are small, charter, live-aboard or a barge, and writing any of them would describe a boat the document does not. Its gear carries the vessel half of §6.3 and §6.12: the twinset and the two sidemount steels go out as `<tank>` pieces carrying `<tankmaterial>` and then `<tankvolume>` after their names, each piece's `working_pressure` and `dive_time` reported `dropped`, and the sidemount pair's two `<tankdata>` each carry a second `<link>`, to its vessel, after the mix's and beside its own `<tankvolume>`; the twinset, linked from no cylinder and on no dive's list, has no `<equipmentused>` link. It is also the **other** half of the device fold: its gear list holds no computer, so the device matches nothing and gets a `<divecomputer>` of its own with a non-UUID id and a `<link>` from the dive — the one case where reading the written file back returns a gear item the input never had. That its device carries a `name` is what puts it inside that exception rather than beside it: a nameless device on an element of its own gets an empty `<name>`, which comes back as no gear item at all. Its third dive starts on a date alone, the corpus's only such start going out, and is written as the bare `<datetime>` [`docs/uddf-writing.md`](../docs/uddf-writing.md) chooses over midnight, its readout-only recording reported `dropped` with nothing of it written; its recording's `salinity` and oxygen clocks are each reported `dropped`, while its surface pressure goes out as the dive's `<surfacepressure>`. Its first site's `other_names`, `altitude` and depth range are written — two `<aliasname>`s after the `<name>`, an `<altitude>` of `0` beside the pin in `<geography>`, and a `<sitedata>` with `<maximumdepth>` before `<minimumdepth>` — and its `external_ids`, `water_type`, `entry_types` and `tags` are each reported `dropped`, UDDF's site having no slot for any of them. The `absent` half is its second dive and its third trip part: no maximum depth, no time in the water and a cylinder with no start pressure, so `<greatestdepth>`, `<diveduration>` and `<tankpressurebegin>` are each written as the `0` a reader takes back off, and a part with no place gets the empty `<name>` `simpleNamedType` requires. Its trip is the corpus's only three-`<trippart>` one, and the three are the three shapes a part comes in: a place with dates, a place with none — which writes no `<dateoftrip>`, that being the one thing here that costs nothing — and dates with no place; each place goes out in both the part's `<name>` and its `<geography><location>`, with its coordinates beside it. Its contact goes out as a `<divebase>`, its roles reported since the slots say back two of its four, linked from the first dive after its two sites and copied onto the first part as an `<accomodation>` typed `hotel`; the course's, the card's and the service record's references to it go with their records. Its four people go out as `<buddy>` elements after the owner; the first dive links its `instructor` and its `student` as plain links with their roles reported, the second its `buddy` and the third its role-less reference as the same plain link, reported since it reads back as `buddy`, and the trip's people and the courses' are reported, with the certification's `instructor_uuid` going with the certification. J. Harbord's `created_at` and `extensions` are reported, as the contact's are. |
+| `technical-dive.divejson` | `valid/technical-dive.divejson` | Everything the first one cannot reach, being hand-built to hold what no UDDF export carries. The `dropped` half of the report: `courses`, `certifications`, `gear_sets` and gear service, which UDDF has no slot for; `species` and the dives' sightings, whose slot a writer could fill only by inventing a class for each; `role` and `usage` on a sidemount pair and its staged deco cylinders; a ceiling channel; a trip part's bounding box, and a dive site's locality entire but for its name — its centre and its box, which is two findings off one record where a part loses one; the gas numbering UDDF cannot record; `shears` and the `backplate` landing in `<variouspieces>` and reading back as `other`, and the `wing` landing in `<buoyancycontroldevice>` and reading back as `bcd`, each reported; a `bookmark` carrying a label, which keeps its type and loses the label; an event with a label and no type, which goes out as a `<setmarker>` carrying the label; the `deco_model`, `tts` and `surface_gradient_factor` its document now carries, each reported `dropped` — the first because UDDF's `<decomodel>` requires a tissue table this format has no member for, the other two because UDDF has no element at all; an empty note, which no UDDF file can spell; a device's `firmware`, for which `equipmentPieceType` has no element; and the diver's `emergency_contacts` and `portrait_file` and an insurance's `number`, which UDDF has no element for either — the insurance itself is written, as a `<diveinsurances>` entry carrying its provider. Its first dive's `type`, `rating`, `air_temperature` and `current` are written — `<apparatus>open-scuba</apparatus>` after the kit, a `<ratingvalue>` of `8`, twice the five-step rating, a Kelvin `<airtemperature>` after the `<datetime>` and `moderate-current` — and its `tags`, `waves`, `weather` and `boat_name` are each reported `dropped`, UDDF having no element for any of them; so is its `entry_type` of `boat`, since UDDF's boats are small, charter, live-aboard or a barge, and writing any of them would describe a boat the document does not. Its gear carries the vessel half of §6.3 and §6.12: the twinset and the two sidemount steels go out as `<tank>` pieces carrying `<tankmaterial>` and then `<tankvolume>` after their names, each piece's `working_pressure` and `dive_time` reported `dropped`, and the sidemount pair's two `<tankdata>` each carry a second `<link>`, to its vessel, after the mix's and beside its own `<tankvolume>`; the twinset, linked from no cylinder and on no dive's list, has no `<equipmentused>` link. It is also the **other** half of the device fold: its gear list holds no computer, so the device matches nothing and gets a `<divecomputer>` of its own with a non-UUID id and a `<link>` from the dive — the one case where reading the written file back returns a gear item the input never had. That its device carries a `name` is what puts it inside that exception rather than beside it: a nameless device on an element of its own gets an empty `<name>`, which comes back as no gear item at all. Its third dive starts on a date alone, the corpus's only such start going out, and is written as the bare `<datetime>` [`docs/uddf-writing.md`](../docs/uddf-writing.md) chooses over midnight, its readout-only recording reported `dropped` with nothing of it written; its recording's `salinity` and oxygen clocks are each reported `dropped`, while its surface pressure goes out as the dive's `<surfacepressure>`. Its first site's `other_names`, `altitude` and depth range are written — two `<aliasname>`s after the `<name>`, an `<altitude>` of `0` beside the pin in `<geography>`, and a `<sitedata>` with `<maximumdepth>` before `<minimumdepth>` — and its `external_ids`, `water_type`, `entry_types` and `tags` are each reported `dropped`, UDDF's site having no slot for any of them. The `absent` half is its second dive and its third trip part: no maximum depth, no time in the water and a cylinder with no start pressure, so `<greatestdepth>`, `<diveduration>` and `<tankpressurebegin>` are each written as the `0` a reader takes back off, and a part with no place gets the empty `<name>` `simpleNamedType` requires. Its trip is the corpus's only three-`<trippart>` one, and the three are the three shapes a part comes in: a place with dates, a place with none — which writes no `<dateoftrip>`, that being the one thing here that costs nothing — and dates with no place; each place goes out in both the part's `<name>` and its `<geography><location>`, with its coordinates beside it. Its contact goes out as a `<divebase>`, its roles reported since the slots say back two of its four, linked from the first dive after its two sites and copied onto the first part as an `<accomodation>` typed `hotel`; the course's, the card's and the service record's references to it go with their records. Its four people go out as `<buddy>` elements after the owner; the first dive links its `instructor` and its `student` as plain links with their roles reported, the second its `buddy` and the third its role-less reference as the same plain link, reported since it reads back as `buddy`, and the trip's people and the courses' are reported, with the certification's `instructor_uuid` going with the certification. J. Harbord's `created_at` and `extensions` are reported, as the contact's are. |
 | `contacts.divejson` | hand-built | The writing half of §6.18 where `technical-dive` cannot reach it, five contacts. Blue Hole Divers, carrying every member but `extensions` and referenced from all five hosts, as a `<divebase>`. Reefside, a shop and nothing else, as a `<business><shop>`, the one slot that says its role back and the only contact here whose `roles` is not reported. Northern Star Liveaboards as a `<divebase>`, and as the copy on the part spent aboard, typed `boat`. Grandma's house, a name and a role, which two parts stay at: a name-only base and two copies of it, which a reader folds back into one contact where one that did not fold would return three. And a guest house also called Reefside, a name and a role, which the last part stays at: its name being the shop's, that part gets no copy and its accommodation is reported, and with no copy naming it and no dive linking it, its name-only base is one a reader skips, so it is reported too. |
 | `people.divejson` | hand-built | The writing half of §6.20 where `technical-dive` cannot reach it: five people and no diver, so the `<owner>` the `<buddy>` elements need goes out as the bare `owner` with empty names, which reads back as no diver. Mona Salem, carrying every member, is the `guide` on two dives at Blue Hole Divers, which goes out as a `<divebase>` holding one `<guide>` for her that both dives link, and the `guide` on a third whose contact is a shop, where the reference is a plain link and its role is reported. Karim, a one-word name with an empty `<lastname/>`, is a `buddy`, a `student` and a `companion` on three dives, the last two roles reported. Ahmed Fathy, written with two spaces between his names, goes out split at the first space and reads back with one; he is one dive's role-less reference — a plain link that reads back as `buddy`, reported — and another dive's `guide` with no base to hang it on. Leila Ben Ali, split into `Leila` and `Ben Ali`, is a dive's `instructor`, reported, and the instructor of a course and of its card, neither of which UDDF has. Nour Haddad is only the trip's `companion`, and goes out as a `<buddy>` all the same, coming back as a person nothing references; the trip's people are reported. |
 | `owner-profile-only.divejson` | `uddf/owner-profile-only.divejson` | The owner that records a person and names nobody, going out: a diver with a uuid and a `born_on` and no name or email still gets a `<diver>`, under `<owner id="diver-<uuid>">` because the document records something about the person, with the empty names `personalType` requires beside the `<birthdate>`. The written file is its reader pair's input again, `<generator>` aside. |

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/accommodation-dangling-reference.divejson

@@ -602,7 +602,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/address-without-country.divejson

@@ -602,7 +602,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/agency-other-missing.divejson

@@ -362,7 +362,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/avg-depth-exceeds-max.divejson

@@ -362,7 +362,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/bad-version.divejson

@@ -362,7 +362,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/bbox-missing-corner.divejson

@@ -361,7 +361,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/bbox-south-exceeds-north.divejson

@@ -362,7 +362,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/bbox-without-position.divejson

@@ -358,7 +358,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/boat-name-empty.divejson

@@ -662,7 +662,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/boat-name-too-long.divejson

@@ -662,7 +662,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/channel-length-mismatch.divejson

@@ -363,7 +363,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/contact-roles-repeated.divejson

@@ -602,7 +602,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/course-agency-other-without-agency.divejson

@@ -554,7 +554,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/course-dates-reversed.divejson

@@ -362,7 +362,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/current-unknown.divejson

@@ -662,7 +662,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/cylinder-gear-dangling-reference.divejson

@@ -698,7 +698,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/cylinder-gear-repeated.divejson

@@ -698,7 +698,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/dangling-reference.divejson

@@ -363,7 +363,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/deco-model-gf-order.divejson

@@ -369,7 +369,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/device-empty-member.divejson

@@ -375,7 +375,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",

{divejson-0.26.0 → divejson-0.28.0}/fixtures/invalid/dive-duration.divejson

@@ -697,7 +697,12 @@
   "species": [
     {
       "uuid": "0198a6f0-1111-7060-8000-000000000060",
-      "aphia_id": 289445,
+      "external_ids": [
+        {
+          "registry": "worms",
+          "identifier": "289445"
+        }
+      ],
       "scientific_name": "Antipathella fiordensis",
       "common_name": "Fiordland black coral",
       "rank": "Species",