The 2 PAGE sub-record is independent of the 3 TEXT and 3 DATE sub-records. These latter two are subordinate to a 2 DATA sub-record that you don't see.
This is one of the not-so-tidy features of the GEDCOM specification - sub-records with identical level numbers can appear in any order, even when the order doesn't make much sense.
You see the same behaviour in other Fact records, such as OCCU, MILI, ...
A cure for this untidiness is on my to-do list, but it has very low priority because it's just a cosmetic bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The different place of the source PAGE data when we define and update the object data and the blank fields in the middle will cause me and my users not to see this data when the source data is edited.
I will anyhow leave the updated priority of this posting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm bumping the priority to "3", but leaving the bug unassigned for now. I don't like this either, but we can't just tackle the 1 SOUR records (2 SOUR seems to be OK) -- we need a more general solution for all 1-level facts where the order of the sub-records matters.
I hope someone else will take this on before I get to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1198414
Originator: NO
The 2 PAGE sub-record is independent of the 3 TEXT and 3 DATE sub-records. These latter two are subordinate to a 2 DATA sub-record that you don't see.
This is one of the not-so-tidy features of the GEDCOM specification - sub-records with identical level numbers can appear in any order, even when the order doesn't make much sense.
You see the same behaviour in other Fact records, such as OCCU, MILI, ...
A cure for this untidiness is on my to-do list, but it has very low priority because it's just a cosmetic bug.
Logged In: YES
user_id=959928
Originator: YES
For me it is not only a cosmetic issue.
The different place of the source PAGE data when we define and update the object data and the blank fields in the middle will cause me and my users not to see this data when the source data is edited.
I will anyhow leave the updated priority of this posting.
Logged In: YES
user_id=1198414
Originator: NO
I'm bumping the priority to "3", but leaving the bug unassigned for now. I don't like this either, but we can't just tackle the 1 SOUR records (2 SOUR seems to be OK) -- we need a more general solution for all 1-level facts where the order of the sub-records matters.
I hope someone else will take this on before I get to it.