You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: