Extension tags converted to URIs during parsing

[glamberson]

Extension Tags Converted to URIs During Parsing

Bug Description

When parsing GEDCOM 7 files with extension tags declared in SCHMA, the parser converts the extension tag names to their URI values, making it impossible to identify which extension tag was used.

Steps to Reproduce

import gedcom7

test_gedcom = """0 HEAD
1 GEDC
2 VERS 7.0
1 SCHMA
2 TAG _TEST https://example.com/test
0 @I1@ INDI
1 NAME John /Doe/
1 _TEST Some test data
0 TRLR"""

structures = list(gedcom7.loads(test_gedcom))

for struct in structures:
    if struct.tag == "INDI":
        for child in struct.children:
            print(f"Tag: {child.tag}")

Expected Behavior

The child tag should be _TEST (the actual tag used in the file).

Actual Behavior

The child tag is https://example.com/test (the URI from the SCHMA declaration).

Impact

This makes it impossible to:

1. Identify which extension tag was actually used in the file
2. Process extension tags differently based on their tag name
3. Export GEDCOM 7 files with the same extension tags that were imported

Additional Information

• Version: gedcom7 0.4.0
• Python: 3.13.5
• This behavior is particularly problematic when multiple extension tags map to the same URI for different purposes

Suggested Fix

The parser should preserve the original tag name, perhaps storing both the tag and its URI:

• tag property: The actual tag from the file (e.g., "_TEST")
• uri or type_id property: The URI from SCHMA (e.g., "https://example.com/test")

This would maintain backward compatibility while allowing access to the original tag name.

[DavidMStraub]

This is not a bug, it's an intentional design decision. It might have been a suboptimal one, but let's first discuss why I made it.

The GedcomStructure object has a tag attribute on the basis of which downstream import libraries (such as gramps-gedcom7) will decide what to do with the structure.

For "documented extension tags" such as this one, the GEDCOM specification states (emphasis mine):

The meaning of a documented extension tag is identified by its URI, not its tag. As such each docu‐
mented extension tag needs its own URI: it is its URI, not its tag, that defines its meaning.

Consequently, I found it more appropriate to identify the tag by its URI (which must be unique across extensions) rather than its tag string.

[glamberson]

Hi David, OK I understand your reasoning. But doing this breaks roundtripping and creates problems both real and esoteric trying to figure out what tag is used (different tags CAN have the same URIs , and if you are troubleshooting what tag was used you'll have a very bad time of it having to scrounge around trying to map URIs to tags. Besides GEDCOM does also explicitly say in other places that the tags are the primary identifier in GEDCOM, and after all the file format uses tags. Anyway I think you can see how it can be problematic, so if you could just include both that would be much better, and particularly for extensions. Besides, let's face it. GEDCOM 7 without extensions really isn't that much of a get which is exactly why adoption has been so slow. This is what I'm trying to help fix, and I"m trying to help position GRAMPS to be in a very good spot regarding the next killer app in genealogy: research support.

So for all those reaons I hope you'll consider altering this little aspect of your implementation. I'm looking at the oterh work I did now and deciding how to best move forward. Thanks for your attention.
Regards, Greg Lamberson

[DavidMStraub]

But doing this breaks roundtripping

This is an excellent argument, so I agree this needs to be changed.

and creates problems both real and esoteric trying to figure out what tag is used (different tags CAN have the same URIs , and if you are troubleshooting what tag was used you'll have a very bad time of it having to scrounge around trying to map URIs to tags.

I would assume that it's much more likely that two developers working on Gedcom export of different pieces of software are much more likely to have a clashing tag name than to have a clashing URI - I would be perfectly happy making URL uniqueness an assumption of an import library. After all, you have to assume something.

So I would see it like this:

1. Use URI to determine tag type, but store tag name to ease roundtripping/export
2. If URI is missing, use tag name to determine tag type

GEDCOM 7 without extensions really isn't that much of a get which is exactly why adoption has been so slow

I'll be honest, as a Gramps user I don't need Gedcom, I'm perfectly happy with Gramps XML. So my main motivation for implementing Gedcom support is to allow migration to or import into Gramps. For this scenario, the main difficulty is implementing extensions that other softwares have come up with, not so much implementing the Gramps data model itself.

[glamberson]

David,

This is an excellent argument, so I agree this needs to be changed.

Great, thanks. Yes I consider that the biggest issue. I can figure out how to deal with the issue in a couple of other way, but I don't really care for them.

So I would see it like this:

1. Use URI to determine tag type, but store tag name to ease roundtripping/export
2. If URI is missing, use tag name to determine tag type

However you want to do it is great with me. I'm glad you'll add the tag alongside the URI somewhere. That's what I need.

I'll be honest, as a Gramps user I don't need Gedcom, I'm perfectly happy with Gramps XML. So my main motivation for implementing Gedcom support is to allow migration to or import into Gramps.

Yes that's apparent, and always has been. In fact if I weren't so arduously trying to bridge these worlds I wouldn't even mess with GEDCOM7 for GRAMPS and instead if anything I'd be working on GEDCOMX for interoperability. That's much more suitable for GRAMPS and for the otehr work I'm doing. But the user community is stuck in these simple apps, and we have to have a bridge to make any progress in advancing the tools that are available in the genealogy sphere.

For this scenario, the main difficulty is implementing extensions that other softwares have come up with, not so much implementing the Gramps data model itself.

I'm living the pain of that myself. Tomorrow I have a Zoom call with 2 of the GECOM board members to discuss both a couple of my extension proposals and to sort of strategize how to squeeze the most goodness out of what can be done with 7 while still making the use of the extension palatable and implementable on the app side. Earlier this week I pointed out to one very thoughtful developer that his citation templates were great but would never get implemented because he chose BASH syntax. There are exactly ZERO BASH parsers in any language that I know of. He hasn't finally agreed on a choice but he's looking at Liquid now.

This is also why digging in and trying to understand this from your perspective and contributing here is so useful. I have ideas for how to proceed, but if they're not parcticable in terms of mapping into an actul app they're useless. I'm struggling with this issue for evidence right now. The next few days should get it ironed out one way or another.

At the VERY least I'll have my TAG extension ready for use in a few days I hope. That's a no-brainer.

Thanks!
Greg