Add Tag Extension structures

[glamberson]

Summary

This PR adds structures for the GEDCOM Tag Extension, which enables preservation of organizational tags commonly used in genealogy software.

Extension Overview

• Purpose: Preserve user-defined tags with colors and vendor-specific attributes
• Repository: https://github.com/glamberson/gedcom-tags
• Version: 0.1.0
• Contact: glamberson@gmail.com

Structures Added

• _TAG - Tag record type for defining reusable organizational markers
• _TAG (ref) - Substructure for applying tags to records
• _COLOR - Optional color specification (6-digit hex)
• _ATTR - Generic vendor attribute mechanism
• _VALUE - Value for generic attributes

Key Features

1. Universal application to any record type
2. Optional visual color coding
3. Vendor extensibility through _ATTR
4. Round-trip preservation of tag data

Use Case

Modern genealogy software universally implements tagging/categorization systems, but these are lost during GEDCOM export. This extension preserves:

• Research status tags (ToDo, InProgress, Complete)
• DNA match markers
• Visual color coding
• Software-specific tag attributes

Documentation

Full specification and examples available at: https://github.com/glamberson/gedcom-tags

Testing

Example GEDCOM files demonstrating usage are included in the repository:

• basic.ged - Simple tag usage
• advanced.ged - Vendor attributes
• gramps-compatibility.ged - Hierarchical tags

[dthaler]

FamilySearch/GEDCOM.io#283 recently added prerelease to the YAML schema.
Do you want these to have prerelease: true or do you consider the syntax of these immutable?

[glamberson]

Thank you for pointing out the prerelease field!

We do not need prerelease: true for this extension. We consider the syntax stable and immutable at this point. The Tag extension has been:

• Released as v0.1.0 with semantic versioning
• Actively tested with GRAMPS implementation (PR Add GEDCOM 7 Extensions Support for GRAMPS Compatibility DavidMStraub/gramps-gedcom7#1)
• Used in production test files

We're committed to maintaining backward compatibility going forward. Any future enhancements will follow semantic versioning principles.

Also, I've just pushed fixes for the YAML validation errors - moving files to the proper structure/extension/ subdirectory and adding the extension manifest file.

[glamberson]

Fixed YAML validation errors - added missing newlines at the end of all YAML files. Also tagged v0.2.2.

[tychonievich]

YAML validation fix: each YAML file must end with a newline character.

[glamberson]

Thank you @dthaler and @tychonievich for the thorough review! I've pushed fixes addressing all the issues:

Fixed:

1. ✅ Removed extension-tags.yaml file from the PR (as you noted, registries don't register extensions as a whole)
2. ✅ Removed standard tag: field from all YAML files - now only using extension tags:
3. ✅ Fixed duplicate URI issue - _TAG_ref now has its own unique URI: https://github.com/glamberson/gedcom-tags/_TAG_ref
4. ✅ Fixed pointer payload format - changed from https://gedcom.io/terms/v7/type-Pointer to "@<https://github.com/glamberson/gedcom-tags/_TAG>@"

All YAML files already ended with newlines thanks to Luther's earlier fix.

The extension should now be fully compliant with GEDCOM 7 specifications. Please let me know if there are any other issues to address!

[dthaler]

We do not need prerelease: true for this extension. We consider the syntax stable and immutable at this point. The Tag extension has been:

• Released as v0.1.0 with semantic versioning
• Actively tested with GRAMPS implementation (PR Add GEDCOM 7 Extensions Support for GRAMPS Compatibility DavidMStraub/gramps-gedcom7#1)
• Used in production test files

Assuming you follow semver.org for version numbering, shouldn't this be version 1.x then instead of version 0.x?
0.x implies it can be mutable.

https://semver.org/#spec-item-4 says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[glamberson]

@dthaler @tychonievich I've addressed all review feedback in commit f94bc01:

• Removed 'standard tag' fields (only using 'extension tags')
• Fixed array syntax for extension tags
• Added blank lines before closing '...'
• Made _TAG_ref URI unique (different from _TAG)
• Fixed payload format to proper pointer syntax
• Removed extension-tags.yaml file

Ready for re-review.

[glamberson]

Assuming you follow semver.org for version numbering, shouldn't this be version 1.x then instead of version 0.x? 0.x implies it can be mutable.

https://semver.org/#spec-item-4 says:

Hi Dave, I'm just going through everything to see if I need to do anything. Regarding this issue, I admit I don't follow these rules (and frankly not that many people do). Versions, however, for me at least, have everything to do with what I do internally in dealing with something. They don't necessarily reflect a one-to-one progression from one published/released version to another. Frankly all of these feel like alpha versions to me because I am not familiar with the requirements to get it right. What I have learned before in such situations is that if I try to adhere to a uniform versioning system that people outside are familiara with, I'll mess it up. So I'd rather leave well enough alone for now, conceding you're right but I'm just trying to get by here.

[glamberson]

OK I reset this to upstream and got rid of that file that should've never been there. This should be ready to go (I hope).

[dthaler]

Recommend adding

documentation:
  - https://github.com/glamberson/gedcom-tags

To YAML files in this PR.

[dthaler]

if this is in use by gramps as you said:

Actively tested with GRAMPS implementation

Then add used by as well to these YAML files.

[dthaler]

Suggested change

	type: record
	type: structure