Skip to content
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

PersonPartnership types? #128

Open
star4z opened this issue Sep 22, 2020 · 0 comments
Open

PersonPartnership types? #128

star4z opened this issue Sep 22, 2020 · 0 comments
Labels
question Further information is requested
Milestone

Comments

@star4z
Copy link
Owner

star4z commented Sep 22, 2020

First off, I'm not sure how high a priority it is to support the GEDCOM standard as it is and old standard and doesn't support a wide variety of nuance.
However, GEDCOM is the industry standard, and so it is definitely something we want to have good support for.
In GEDCOM, afaik, partners are either husbands or wives, with no alternative values. If this is not true, that would make my life a whole lot easier.

The issue is, what is the appropriate tag to use when the partner is not male or female?

I have seen examples of using HUSB or WIFE to represent unmarried partners, so I don't think it's unreasonable to assume that the tags can be used for things other than married partners.
It does not seem unreasonable to me to add a "type" field to PersonPartnerships. However, I would at least want an "other" option for this field, which would not resolve the issue of, what do we do in the case of type "other"?
Also, when parsing GEDCOM, this would prevent us from assuming that husbands in families that are not married are not "husbands", and so would cause us to lose that piece of data in that specific form during conversion.

@star4z star4z added the question Further information is requested label Sep 22, 2020
@star4z star4z added this to the 1.0 milestone Oct 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant