Reinoud
I think we may be getting at cross purposes. When you said
Kaaskop wrote: ↑21 Jun 2022 09:01
I thought FH is following the Gedcom standard?
They do take pride in being one of the software products that does not have its own database and attempts to (pragmatically) follow the GEDCOM standard.
With statements like that (particularly I suspect in the Anglo-Saxon world) there is "following" and "following" (like the UK "complying with the EU Withdrawal Agreement" whilst admitting its proposals "breaks international law in a very specific and limited way"?! [ref:
DW])
There are also choices "allowed" within the standard and there are "tolerated non-conformances".
I suspect the "minimal support" (i.e. via the "All tab") is a pragmatic attempt to follow the standard making use of "choices", "tolerated non-conformances" and "ambiguities". A number of us are questioning whether going forward that is adequate.
Kaaskop wrote: ↑21 Jun 2022 09:01
It would be nice if the standard behavior of FH (at least in the underlying structure) would be based on name pieces instead of on name personal.
I read the above as you saying "by default FH should use the name pieces rather the NAME" - which I suspect requires a major change to ensure that (for instance) everywhere:
- where FH has previously called NAME it has to call the three Piece Fields
- where it has called the qualified names (NAME:GIVEN, NAME:GIVEN_ALL and NAME:SURNAME etc.) it has to use the relevant Piece Field,
- when it has called a subroutine to sort on NAME:SURNAME_FIRST, it has to use SURN+GIVN (or some would say SPFX+SURN+GIVN - which is to be built into the underlying structure?)
- etc. etc.
That I would see as going against the grain which is to by default work with just the single NAME field and use NAME:GIVEN, NAME:GIVEN_ALL and NAME:SURNAME when it needs a "piece".
The alternative is to meet the problem at "Name" input/edit/delete allowing the option to enter Piece Parts and then to possibly automatically (rather than by plug-in) build a NAME field that can be used in the way that FH already does - which may look (to the user) as if it is using the Name Piece Parts by default. But I suspect any automatic build of the NAME is going to create sufficient problems to be a significant irritation and therefore there needs to be an option to manually build the NAME field.
If we want to see an enhancement (either in V7.1 or V8.0) we have to accept the way that CP has built the program and frame our wish list requests to at least work in sympathy with the "way it is". The above paragraph is how I think we may best do this. Others may have better ideas which is why we iteratively discuss possible wish list requests.
Kaaskop wrote: ↑21 Jun 2022 12:30
If you use GIVN, SPFX and SURN every software program can easily construct the NAME (except FH) by doing that you can have the advantage of both: more flexibility with entering data and you follow the Gedcom standard. So Name stays mandatory but is build from the separate fields.
This is why I think we may be at cross purposes and in danger of having a vigorous agreement!
I do not know other programs and how they can be confident that they can build NAME from the pieces as I suspect that NAME does not always equal GIVN+" "+SPFX+" "+SURN.
For instance if you have:
GIVN: Sebastien
SPFX: de l'
SURN: Aubespine
You have to program for the situation where you want to create
Sebastien de l'Aubespine without a space between SPFX and SURN. Are we confident that every software program can easily construct the NAME (except FH) in a reliable way?
With FH giving primacy to NAME the user can enter
Sebastien /de l'Aubespine/ and be confident that what was put in is what comes out in diagrams and reports etc.
Those of us contributing to this topic are pretty much agreed that whilst giving primacy to NAME handles "presentation" pretty well, we are agreed that there are circumstances where this give significant problems in sorting and filtering particularly when there are surname prefixes.
If we are saying, "OK let's raise our eyes from the simple "given_names surname" structure that we are used to" (two simple elements), at the same time as considering a single instance of where this structure is unsatisfactory (where there are surname prefixes - three elements), we ought to consider, "are there other name structures that might be problematic - or which could offer market opportunities - that could be considered at the same time?".