Planning for 7.1 and/or 8.0 next

[tychonievich]

The steering committee today had a conversation about proposals to make more flexible records for several current substructures: PLAC (location), SOUR (citation), and the event/fact types. Some similar points could be made of non-record proposals like a revised NAME structure.

We can technically add these to 7.1, either as "pick one of the two", like we have for NOTE vs SNOTE; or as a "include both" pointer substructure to the current non-pointer structures, like we have for name parts (GIVN and so on). A disadvantage of "pick one of the two" is that it could be some applications understand only one of the two and lose data. A disadvantage of "standardized form" is significantly increased file size and duplicate data that could get out of sync, especially if interacting with an application that does not properly implement that structure.

We could also wait until 8.0 and remove the old structures, replacing them with records. This would force applications to adopt the new model in order to handle any 8.0 file. One of the six steering committee members asked if this meant we should consider skipping 7.1 and jumping to 8.0. (for context: prior to 7.0, a breaking change in GEDCOM was released every 2–3 years)

• One view: 8.0 needs to be years out and we shouldn't think about that yet.
• One view: 7.0 is not different enough from 5.5.1 to cause some applications to see a big win. We should add something big.
• One view: we should send a questionnaire/survey to applications we know how to contact, with an outline of the pros and cons of the options. This seemed valuable to all six of us.
• One view: add the features in 7.1, picking one of the two options above (weak preference for the "include both" instead of "pick one" option). This means we can stop recommending using particular extensions, and also pave the way for 8.0 later. Several agreed.
• One view: we should draft out what both the 7.1 and 8.0 versions would look like and then discuss. Making two changes is (7.0→7.1→8.0) is extra work to avoid if we can, so if the 7.1 solution has problems we should wait until 8.0.
• One view: we could develop 7.1 and 8.0 in parallel, supporting both the 7.x and 8.x standard concurrently for some time.

We didn't arrive at a final conclusion, but are leaning toward reaching out to application developers, and meantime working on what these would look like in 7.1 and/or 8.0, expecting that this work will be modifiable for the other if there's consensus on which we should do.

We welcome the opinions of the community here on this topic as well. In this discussion we're more interested in the process than in the specific inclusion of those three record types; there will no doubt be much back-and-forth on the nuances of those, which we will have but don't want to distract from the version progression discussion here.

[Norwegian-Sardines]

If a concept such as a new citation record or some kind of new place record structure can be included in v7.1 that does not adversely affect the use of the v7.0 concepts then having both (with the caveat that in v8.0 the old way will be depreciated) we should look into doing that!

Concentrating on v8.0 but pushing down some concepts to v7.1 that are compatible can be valuable toward Move GEDCOM forward with a way to get better compliance for v8.0 because we moved a little in that direction with v7.1.

A questionnaire would only be valuable after a well defined new approach has been well thought out and fully developed showing how much better the new concept is for genealogist and data creation. I worry that a survey to some application developers would color their opinions of potential changes toward maintaining the status quo (requiring less redesign and changes to their application) but not actually moving GEDCOM to a better place in international/multi-cultural/multi-lingual/historical centric data exchange.

I think v7.0 is an easy move for many application because they don’t really support v5.5.1 and I don’t think we removed anything that significant from v5.5.1 already used by them. It is probably more of a big deal for application that are closer to 100% v5.5.1 and may need more significant changes to maintain their close to 100% compatibility, while also excepting back release GEDCOM files.

[mother10]

This will end up in a long post again, I am sorry for that.

First a reaction on the previous 2 posts:
There is 1 thing that to me seems very important. Make sure that whatever is done cannot create a mess.
By that I mean the way people now use extensions. In an earlier post of me, I showed how many extensions there are, and I am sure I missed a lot. In GEDCOM, extensions were implemented (Version 5.3 draft), to give users the possibility to add things that were not specified in GEDCOM at a given time. But that should be defined in a future GEDCOM version.

But the whole thing exploded (kind of) and now we face an almost impossible amount of extensions, some meaning the same, under different names, others only used maybe once. Each developer has his own ideas of what should be in GEDCOM and added extensions for that, without thinking of what other programs should do with it.

Now in the previous posts in this thread, (as far as i understand) some people want to add 2 versions of a definition/structure (temporarely) in the following version, to later be removed in the version after that.
I would say: dont do that, if something has to change do it in one blow, not in 1 versions next to eachother and later remove 1.
Dont give developers (me included!!!) the freedom to choose how to do something, as (Dutch expression) "when you give them 1 finger, they grab the whole hand"
And you might create more mess.

About the views: yes make the next version different enough, add 1 or more big things.

The questionaire: Same thing, developers will look at their own program and choose accordingly, just as Norwegian-Sardines said. They will not think about whats best for GEDCOM.

Next version: Most important, make it worthwile. Whether that be 7.1 or 8.0, add enough changes, and or important changes so it becomes interesting to follow. And at the same time it will show developers the direction GEDCOM will take, and kind of warns them that if they want to stay aboard, they will have to follow.
Define a priority for what will change. And add things in the next version with the highest priority. Why? because the version after that will be further away and there will be things people want very much to be added.
Also see below.

Now my additions:

From reading up and down the GEDCOM spec, and my experiances with how GEDCOM is implemented in the 2 programs I use, and how developers react on questions about how to do things, I more and more get the feeling GEDCOM might need more strict rules. And well the sooner the better.
I searched the latest 7.0.14 for the word "recommend", and it gave me 53 times that word, so there are a lot of places in the GEDCOM specification, that leave the user/developer a choise in how to do things.
To me it sounded a bit like a law book saying "it is recommended you do not kill someone".
I am joking a bit, but maybe the very next GEDCOM, should be way more strict!
Take out a lot of "recommendings", and maybe change some "{0:1}" into "{1:1}" to force people to put in the information and make the GEDCOM more understandable.

For instance the header, that is allowed to be:

0 HEAD
1 GEDC
2 VERS 7.0.14

Now how usefull a header is this 3-line thing? But this is according to the spec am I right?

I would say this should be the mandatory minimum:

0 HEAD
1 GEDC
2 VERS 7.0.14
1 SOUR
2 NAME
2 CORP
3 ADDR
4 CITY
4 CTRY
3 EMAIL
1 DEST
1 DATE
2 TIME
1 SUBM
1 COPR
1 LANG
1 PLAC
2 FORM

There are lots of problems when there is no PLAC in the header, I am one of the many that struggle with this.
Also, if a developer creates a program, he should give minimum info about name city email and such of his program.
DEST should be there too. For Dest maybe we could add
1 DEST
2 VERS
Where VERS is same as with GEDC. That would mean: any program following that GEDCOM version, then names are not so necessary.

And why is there only 1 NOTE possible in the header?
One of the programs I use, has the possibility to have many remarks concerning the whole tree (not just 1 entity).
Do I need to put them all in 1 NOTE?
All other places where NOTEs are allowed, have the possibility to have {0:M} for the NOTE structure, why not the Header?

Further about the Header, give it a CREA and a CHAN, after all it is possible to change the PLAC of a GEDCOM and maybe other header info. So have that reflected by these 2 tags.
Programs can convert a GEDCOM into another version, give the possibility to reflect that.

So there should be more things in the next version that are mandatory in my opinion.
If you want to join the Olympics you have to obey the rules!
Same here!

There are more things but I will put that in a separate Post.