Versions & conversion matrix
Linea Codex supports three GEDCOM versions — 5.5, 5.5.1, and 7.0 — and edits each under its own rules. This page is the consolidated reference for two questions the cookbook recipes keep pointing back to: what does each version support? (the feature matrix below) and what happens to my data when I move between versions? (the conversion tables that follow).
The grammar itself — lines, levels, tags, pointers — is the same across all three versions; see How GEDCOM works. What changes is which tags are valid, what they mean, and how a few structures are shaped. We strive to be as standards-compliant as possible in every version, and conversion is held to a clear promise: a compliant file in yields a compliant file out; anything else is converted best-effort, with every loss surfaced rather than hidden.
Feature matrix
Section titled “Feature matrix”A row’s cell is ✓ (supported), ✗ (not available), or added (introduced in that version and kept thereafter). “Added” in a column means every later column inherits it. Each row links to the recipe that covers it in depth.
| Feature | 5.5 | 5.5.1 | 7.0 |
|---|---|---|---|
SEX values ↗ | M F | adds U | adds X (keeps U) |
Name TYPE ↗ | ✗ | added (lowercase, free-text) | enum (uppercase) + PHRASE |
Name pieces repeatable (GIVN, SURN, NPFX, SPFX, NICK, NSFX) ↗ | once each | once each | repeatable |
FONE / ROMN (phonetic / romanized variants) ↗ | ✗ | added | replaced by TRAN |
TRAN + LANG (name / place / note translations) ↗ | ✗ | ✗ | added |
MAP / LATI / LONG (coordinates) ↗ | ✗ | added | ✓ |
| Calendar form ↗ | @#D…@ escape | @#D…@ escape | bare tag (JULIAN) + BCE |
| Date phrase form ↗ | inline INT … (…) | inline INT … (…) | PHRASE substructure |
FACT (generic attribute) ↗ | ✗ (EVEN only) | added (TYPE required) | ✓ |
NO (event did not happen) ↗ | ✗ | ✗ | added |
RESI text payload ↗ | structured only | structured only | text payload allowed |
SNOTE (shared-note record) ↗ | ✗ (shared NOTE) | ✗ (shared NOTE) | added |
Note MIME / LANG ↗ | ✗ | ✗ | added |
CONC + 255-char line limit ↗ | ✓ | ✓ | removed (CONT only) |
Inline BLOB media ↗ | ✓ | eliminated | ✗ |
FILE-reference media ↗ | ✓ (also offered) | ✓ | ✓ |
Media FORM value ↗ | short code | short code | MIME type |
CROP (media-link region) ↗ | ✗ | ✗ | added |
| GEDZIP packaging ↗ | ✗ | ✗ | added |
SCHMA extension declarations ↗ | ✗ | ✗ | added |
UID / EXID (standard identifiers) ↗ | ✗ (_UID custom) | ✗ (_UID custom) | added |
EMAIL / FAX / WWW (address contacts) ↗ | ✗ | added | ✓ |
HEAD.SUBM (file submitter) ↗ | required {1:1} | required {1:1} | optional {0:1} |
A few entries earn a word more than a cell holds:
- Inline
BLOBis the single biggest media difference. The 5.5.1 spec states “the BLOB tag was eliminated”; 7.0 has no inline media either. On import, Linea Codex extracts any 5.5BLOBpayload to a real file (recorded internally as_EMBED), so you edit it as a file regardless. See Media & files. - Calendar form changes shape, not capability:
@#DJULIAN@ 14 FEB 1721in 5.5.x becomesJULIAN 14 FEB 1721in 7.0. 7.0 also adds theBCEepoch and requires a year on every date. - Note
MIME/LANGplusTRANtranslations are a 7.0 enrichment of the note structure; 5.5.x notes carry neither.
Conversion: direction by direction
Section titled “Conversion: direction by direction”Conversion always routes through the version-neutral model — never directly between two specific versions — so the same hop behaves identically whichever end you start from (the 5.5 ↔ 7.0 path is two hops chained through 5.5.1). For how to run a conversion — the preview dialog, the deletion list, the downloadable log — see Converting GEDCOM versions.
Two cross-cutting things happen on every conversion, in both directions:
- Cross-references are renumbered densely as records are reshaped, so an
@I1@may not survive as@I1@. The file’s internal pointers are rewritten to stay consistent — but a@xref@is not a stable identifier. For an id that persists, useREFNor (in 7.0)UID/EXID; see Give a record a stable identifier. - Encoding is normalised to one the target allows — converting to 7.0 always lands on UTF-8 (the only encoding 7.0 permits). See Encoding & ANSEL.
Upgrades (toward 7.0)
Section titled “Upgrades (toward 7.0)”Upgrading is the less lossy direction — newer versions are supersets in most respects — but a handful of structures are reshaped rather than copied.
| Structure | 5.5 → 5.5.1 | 5.5.1 → 7.0 | Lossy? |
|---|---|---|---|
Inline BLOB media | extracted to a FILE reference (the file already lives on disk) | already FILE; carried through | No — the bytes are preserved as a file |
Inline FORM under OBJE | relocated to sit under FILE (5.5.1 shape) | — | No |
Inline OBJE block | — | promoted to a standalone OBJE record + a pointer to it | No |
Media FORM value | — | short code → MIME type | No |
Shared NOTE record + pointers | — | renamed to SNOTE record; each NOTE @N@ pointer rewritten to SNOTE @N@ — sharing preserved | No |
FONE / ROMN (phonetic / romanized) | carried through | reshaped to TRAN + LANG where the TYPE has a sanctioned language mapping; otherwise dropped + reported | Partly — an unmapped TYPE is dropped |
| Date / age values | carried through | re-serialised to the 7.0 surface form (bare calendar tag, BCE, no escape) | No for dates |
Header CHAR / GEDC.FORM | carried through | removed (format metadata 7.0 doesn’t use — no genealogical data) | No |
SUBN submission record | carried through | dropped + reported (no 7.0 equivalent) | Yes — but SUBN holds no family data |
In-use _-extension tags | carried through | declared in HEAD.SCHMA automatically, so the 7.0 output documents its custom tags | No — this adds compliance |
The SCHMA auto-declaration is worth calling out: converting to 7.0, Linea Codex declares every
custom (_-prefixed) tag still in use under its own URI base, so the result is standards-clean rather
than carrying undeclared extensions. See When GEDCOM has no tag for it.
Downgrades (toward 5.5)
Section titled “Downgrades (toward 5.5)”Downgrading is where losses concentrate — an older version simply has nowhere to put some newer structures. Linea Codex never blocks a downgrade; it converts as faithfully as it can and surfaces every loss in the preview’s Data that will be deleted list.
| Structure | 7.0 → 5.5.1 | 5.5.1 → 5.5 | Lossy? |
|---|---|---|---|
FILE-reference media | carried through | re-embedded as inline BLOB (where the file resolves); surplus FILE children beyond one are dropped + reported | Partly — multi-FILE records keep one |
SNOTE shared-note record | inlined: the shared text is duplicated as a plain NOTE at every pointer site, and the standalone record is removed | carried through | Yes — sharing is broken: one shared copy becomes several independent ones |
Note MIME / LANG / TRAN | no 5.5.x home — primary note text kept; MIME / LANG surface as validation diagnostics, a note TRAN is dropped + reported | — | Yes |
TRAN (name / place translations) | reshaped to FONE / ROMN where the LANG reverse-maps; otherwise dropped + reported | — | Partly |
FONE / ROMN | — | dropped + reported (5.5 has no name/place variants) | Yes |
MAP / LATI / LONG (coordinates) | carried through | dropped + reported (5.5 has no coordinates) | Yes |
UID | dropped + reported (no 5.5.1 home — use _UID) | carried through | Yes |
NO (negative assertion) | dropped + reported (no 5.5.x equivalent) | carried through | Yes |
EXID | no 5.5.x home — surfaces as a validation diagnostic under the target’s rules | carried through | Yes |
FACT (generic attribute) | carried through | dropped + reported (5.5 has no FACT) | Yes — the attribute is removed |
EMAIL / FAX / WWW | carried through | dropped + reported (5.5 address structure lacks them) | Yes |
SCHMA extension block | removed (5.5.1 has no schema block — format metadata) | — | No |
| Required header structures | injected as needed | CHAR / GEDC.FORM / SOUR / SUBM injected so the output is valid 5.5 | No — this adds required structure |
| Date / age values | re-serialised to the 5.5.x surface form (@#D…@ escape, B.C.) | carried through | No |
| Long text | CONT-only carried through | re-wrapped with CONC to the 255-char line limit | No — text is unchanged |
The shared-note inline is the loss to understand before downgrading from 7.0. Up-conversion preserves sharing with a clean rename; down-conversion has no shared-note construct to rename into, so it copies the text inline at each reference and deletes the one shared record. The text is faithful, but the link between the copies is gone — edit one afterward and the others won’t follow. See Notes for the full before/after.
Chained conversions (5.5 ↔ 7.0)
Section titled “Chained conversions (5.5 ↔ 7.0)”There is no direct 5.5 ↔ 7.0 pack. A 5.5 ↔ 7.0 conversion is two hops through 5.5.1, composed automatically. The upshot:
- 5.5 → 7.0 combines both upgrade hops:
BLOBbecomes aFILE-basedOBJErecord, mediaFORMcodes become MIME types, dates re-serialise to the 7.0 form, and extensions land inHEAD.SCHMA. - 7.0 → 5.5 combines both downgrade hops, so it accumulates both rows of losses above — for
example a 7.0 file with shared notes, coordinates, and
UIDs loses note sharing and coordinates and theUIDs, and itsFILEmedia is re-embedded as inlineBLOB. Review the preview’s deletion list carefully before confirming.
Relabel vs. convert (recap)
Section titled “Relabel vs. convert (recap)”Two distinct operations change a file’s version — pick the right one:
| Relabel | Convert | |
|---|---|---|
| What changes | Only the declared version number | The data, reshaped for the target version |
| How you trigger it | Edit HEAD → GEDC → VERS and save | File → Convert version |
| Media, tags, encoding | Untouched | Migrated per the tables above |
| When to use it | The data already fits the new version’s shape | You’re genuinely moving between versions |
A relabel is correct only when the data already fits the target’s rules (e.g. a file authored as 5.5 that is actually 5.5.1-shaped). Because it reshapes nothing, anything that only exists in the old version’s shape will surface in the validation panel under the new rules — that’s the signal you wanted a conversion instead. Full walkthrough of both, with the preview dialog and the downloadable change log: Converting GEDCOM versions.
See also: The version-independent model (why conversion routes through a common AST) · Validation (the per-version rules every cell here is checked against) · The rule catalog.