User-visibility of extensions

[mother10]

The PLAC tag:

PLAC, as a separate SPLAC entity thats a great idea. Maybe put addres inside SPLAC too? After all both define a position on a map.
Entities and events will then just have a link to an SPLAC, there will be no more then that link, so no other PLAC info inside an event. Just a link.

Both programs I work with now have a way of separately editing places, placenames, their positions and everything related.
So I very much like this idea!
And both programs I use offer the possibility to see for every place, what events of whom, took place there.

PLAC jurisdictions, as it is now:

One of the programs I use, give the PLAC jurisdictions in the language the user is working in, and those different language terms end up in GEDCOM.
So suppose 8 languages and 6 jurisdictions......

Why not do the same as with KIND and TYPE:
Define English terms for all possible jurisdictions and force those terms to be used in a GEDCOM file. Define their sequence too maybe?
Dont accept jurisdictions in all kind of languages, that makes it very difficult for programs to find out what is meant.
Programs will have to kind of "translate" the terms now to see their meaning.
That a program presents the terms to the user, tranlated and all, ok, but inside GEDCOM just the English terms as will be defined in GEDCOM.
Thats the same as now for KIND and TYPE.
Those are translated when presented to the user, not inside GEDCOM.

Also, as stated in my post in #519 , Force a PLAC definition in the GEDCOM header. That should always be there!

The other program I use accepts everything possible as a placename, so a lot of users only use the placename (text), no province, no country, nothing.
And the GEDCOM it outputs has no PLAC tag. So the importing program has no idea how to deal with that.

This is one of the reasons I say: define things in such a way that there is only 1 outcome possible.
The better things are specified the less problems there will be.

Now extensions:
There are already hundreds, and how many are really specified? Hardly any.
How to deal with extensions, for programs that didnot "invent" them, and dont know how to use them, is not really defined either is it?
So every developer does as he pleases.
And users have no idea extensions even exist, they hardly know what GEDCOM is.
As most programs have no special GEDCOM editor, that can show the GEDCOM as it is in the file, users are not aware of them.
They find out the hard way when they import their GEDCOM in a program that didnot create it, so if they want to use another software.
Have seen many examples of that.

Now I was wondering, could it be made extensions can be shown to users?
Suppose we have an ENOTE (extension NOTE) that functions as a normal NOTE. Programs can deal with that as a normal NOTE that can be shown to users.
Then users are more aware they exist.
Inside the ENOTE, will be the lines as they are now as extension.
If a program sees the ENOTE it can process it as a NOTE.
It can look at the first line, the extension itself, if it does not know how to process that one, it does nothing, only shows the ENOTE to the user. And it does not have to look at the other lines inside that ENOTE.
Otherwise it can "convert" the extension to something it can process.

Inside the ENOTE the extension exists on lines with CONT tags, as if they were in the GEDCOM.

0 ENOTE 1 _NEW
1 CONT 2 TYPE 2
1 CONT 2 DATE 10 AUG 2024
1 CONT 3 TIME 20:10:10

Wouldnot this be way cleaner?

[dthaler]

Discussion in GEDCOM Steering Committee 3 SEP 2024:

• We agree that very few extensions are registered so far and we encourage registration of more, even by third parties if necessary. That is, if you are aware of an extension used by an application (even a now-defunct one), it can be registered via the process at https://github.com/familysearch/GEDCOM-registries?tab=readme-ov-file#registering-extensions. Incomplete submissions are also welcome, the committee can use any information available. Issue Possibly usefull info, for the issues with an "Awaiting Use" label. #517 from @mother10 is a good example of such information, which we appreciate.
• Any application can already display extensions to the user if it chooses to
• Users may be confused by displaying the CONT payloads literally. For example if @I1@ were in the payload of some structure in the extension. Pointers could even get out of sync or have dangling pointers if the app were not aware of this.
• In 7.0, extension tags are explained in the header (HEAD.SCHMA), including their payload type that would allow safe editing. That is, the application can determine the syntax of an extension payload even if it cannot determine the purpose of a payload.

[dthaler]

Additional discussion:

• Please use issue Extending SPLAC to include ADDR and PLAC? #536 for additional discussion about the PLAC tag.
• Additional discussion of ENOTE or similar ideas can continue here.
• Changing title of this discussion to match this focus.