-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension registry #204
Comments
My initial thoughts...
No strong opinion here, but if some extensions might also warrant an addition to https://github.com/FamilySearch/GEDCOM/blob/main/version-detection/version-detection.md then having them be in the same repo would make PRs easier to review.
Yes
I would like to see a process for 3rd party submissions, especially if there are known things used by popular apps that no longer have an active owner. As one comparable, a URI scheme can be registered by a third-party (see process in https://www.rfc-editor.org/rfc/rfc7595) and there is a process to later claim ownership.
A web form sounds like more work, to create, maintain, update, so I'd just start with github PRs for now.
Above sounds good to me.
I'd like to allow legacy (5.5.1) extensions in the registry, and those won't have URIs per se.
Yes, I'd put them in the same registry.
Offhand, I might say no, but it's ok if we find a good argument to do so. |
I realize the question I'm asking is not really part of this issue thread but it has been bothering me since v7.0 was introduced. Question: For example: The genealogy application receives a V7.0 GEDCOM from the wild, i.e. a friend sends me a GEDCOM and wants me to help them research some of the branch. My program imports the GEDCOM and comes across an "Extension Tag" that it does not understand or know how to use it within its database. What happens?
How is this Extension Registry valuable to the import process? |
I think of it primarily as an aid for developers. If a developer notices that a lot of files are being submitted with undocumented extension tag I expect it may also be used in some automated validators and compatibility checkers. I could imagine creating a tool that uses it directly to populate a dynamic user interface and automatically handle any extension in the registry, but I doubt that will be very common. Some tools also list tags they failed to import to the user, who could presumably use the registry to figure out what they all meant and thus exactly what data was lost, but I don't expect most users will do that. |
Thanks. Based on what I've seen with various genealogy programs the amount of effort put into updating a database, interface and additional data, I suspect that the incorporation of new "Extensions" will be slow! Personally I would have hoped that a new record type would have been added to the GEDCOM payload working like a "Data Dictionary", similar to what was introduced in GEDCOM v5.3 but as a separate structure which could help the import reconcile the extension quicker and or give the user a specific message that would give a definition of the extension rather than an simple error. |
Discussed in steering committee
|
FamilySearch/GEDCOM-registries#11 updated the GEDCOM-registries repository to copy the extracted files there automatically. |
This is now done |
Now that we have a documented YAML format (https://gedcom.io/terms/format) I think it's time to revisit the idea of an extension registry.
Proposal: we allow community submissions of YAML files for extensions to a common repository where they may be easily located.
In addition to general interoperability gains, this might assist in an extension-to-standard workflow (#17) and in defining additional calendars (#38, #116) and events (#117).
Various questions I think we should answer before creating such a registry:
Should it be part of this repo, the gedcom.io repo, or a different repo?
Note that git hooks and github actions mean we can make this decision independently of if/where it has a web presence.
How should submissions to the registry be managed? Options include
How should files be named?
Existing YAML files all have the same prefix so their filenames are easy to define. But that won't be true for extensions. Some options include
1.yaml
, next is2.yaml
, and so on/
,?
, and#
with other characters)?
, and#
with other characters)What derivative files should be produced?
Should the standardized concepts be included in the registry with the extension concepts?
Should we create URIs in the extension tag registry namespace for extensions registered without a creator-defined URI?
The text was updated successfully, but these errors were encountered: