@VOID@ with PHRASE or with NOTE

[albertemmerich]

The spec says that PHRASE can give details if a pointer to a record is not available. Example with tag ASSO.
However: With tag SOUR the spec shows 2 examples, one of them:

1 DSCR Tall enough his head touched the ceiling
2 SOUR @VOID@
3 NOTE His grand-daughter Lydia told me this in 1980

Should we modify this to:

1 DSCR Tall enough his head touched the ceiling
2 SOUR @VOID@
3 PHRASE His grand-daughter Lydia told me this in 1980

??

[albertemmerich]

If you think about embedded SOUR in 5.5.1 and convert that to 7.0, you should use SOUR.PHRASE and not SOUR.NOTE. Why? Because reconverting SOUR.PHRASE to 5.5.1 is possible. But if you used SOUR.NOTE to take the 5.5.1 content of the embedded SOUR and that SOUR had another NOTE with it, then you have in GEDCOM 7 two NOTE lines: One from SOUR content, and one from earlier SOUR.NOTE. You do not have information, which should be put back to SOUR in 5.5.1.

Reconverting to 5.5.1 will often happen: An application which offers different standard versions for export has to do it...

[dthaler]

Unlike the <<ASSOCIATION_STRUCTURE>>, in the current spec the <<SOURCE_CITATION>> does not permit PHRASE as a substructure, so you cannot have a PHRASE directly under a SOUR.

[albertemmerich]

I know. And I think this is a bug in the spec. We need PHRASE in cases we have the @void@ as replacement for an pointer to a record. I do not see a reason, why SOUR is excluded.
So we should add SOUR.PHRASE to the spec.

[tychonievich]

In the history of GEDCOM 7.0 development, this problem arose because we initially had a SOUR.PHRASE but then got some feedback that it was complicated to implement, so we rolled it back.

Proposal: do something like we did with _LANG: suggest _PHRASE

[albertemmerich]

SOUR._PHRASE is a temporary solution, I implemented it in the 7.0 version of my program.
For GEDCOM 7.1 we should add SOUR.PHRASE to the spec.
PHRASE should be allowed in all cases where a pointer is set to @void@ or where we have enumerated values. Then we can implement that as a module without exception. Now we have to make distinctions which cases are allowed and which need the _PHRASE solution.

[tychonievich]

Note: many applications drop extension tags, so perhaps do not recommend _PHRASE?

Alternative: because structures store the order of NOTEs, we could say that if there's a @void@ then the first NOTE is the meaning of the pointer. But the current spec does not require a phrase for the @void@, making this problematic.