Please do NOT post requests for help here. Use the Help forum for that.
  • Page:
  • 1
  • 2

TOPIC:

GEDCOM 7.0.0 2 weeks 2 days ago #1

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 2 weeks 2 days ago #2

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2065
Did they tell you it was ok to talk about this?
Ken

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 2 weeks 2 days ago #3

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
They didn't tell me. I found it while searching the web ;-)
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 2 weeks 1 day ago #4

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
OK - just had an official announcement about the 7.0 spec and the github.io site.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 2 weeks 1 day ago #5

  • Peter_S
  • Peter_S's Avatar
  • Offline
  • Junior Member
  • Junior Member
  • Posts: 194
General Info: GEDCOM.info
Technical Specs, Tools and Guides: GEDCOM.io

Changelog V7.0.0: GEDCOM.io/changelog/

Possible next steps: see here
Peter

webtrees 1.7.18 and 2.0.16, vesta modules
PHP 7.4.3, MySQL 5.7.25
Webhosting: genonline.de

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 3 days ago #6

  • hermann
  • hermann's Avatar
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 321
What do you think about GEDCOM 7.0? @Greg: do you plan to support this new standard?

There are many steps necessary to convert a GEDCOM 5.5.1 structure to 7.0 (see GEDCOM 5/7 converter ).

In my opinion, there are many improvements in GEDCOM 7, but at least for some years it will be necessary to support both versions.
webtrees 2.0.16 (all available custom modules installed, php 7.4.15, MySQL 5.6) @ ahnen.hartenthaler.eu/
and webtrees 1.7.18 (many custom modules) @ ahnen1.hartenthaler.eu/

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 3 days ago #7

  • bertkoor
  • bertkoor's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Greetings from Utrecht, Holland
  • Posts: 2330
Thanks for sharing the link to the converter, Hermann.
Not because I need a converter, but the README of that project sums up the differences and new structures quite nicely.
stamboom.BertKoor.nl runs on webtrees v1.7.13

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 3 days ago #8

  • hermann
  • hermann's Avatar
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 321
@bertkoor: that was my idea behind sharing this link to the converter (the list is very detailed and precise and gives some insights into what was planned but is marked now as "deferred").

There are two more links, which are maybe helpful (but they are in the German language):
... and still available (from February 2021):
webtrees 2.0.16 (all available custom modules installed, php 7.4.15, MySQL 5.6) @ ahnen.hartenthaler.eu/
and webtrees 1.7.18 (many custom modules) @ ahnen1.hartenthaler.eu/

Please Log in or Create an account to join the conversation.

Last edit: by hermann.
Do you need a web hosting solution for your webtrees site?
If you prefer a host that specialises in webtrees, the following page lists some suppliers able to provide one for you: 

GEDCOM 7.0.0 1 week 6 hours ago #9

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
One "feature" of GEDCOM 7 is that the maximum length of an XREF has been removed. In version 5.5, it was 20 characters.

Databases do not allow you to create indexes on "TEXT" columns - ones that allow unlimited length data.
They can only create indexes on fixed-length columns. In MySQL, the maximum is 255 characters.

This is an issue for applications such as webtrees that use GEDCOM as a data-model and also store their data in a database.

Before 7.0 was released, I requested this this was changed.
groups.google.com/g/gedcomgeneral/c/c8axJO8FBQM

However, that request has now been declined.
github.com/FamilySearch/GEDCOM/issues/3

So, to support GEDCOM 7.0, we must move away from XREFs, and develop our own system for identifiers, URLs, etc.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 5 hours ago #10

  • bertkoor
  • bertkoor's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Greetings from Utrecht, Holland
  • Posts: 2330
> This proposal, if implemented, would be a breaking change and would thus require updating to version 8.0.

Hail hail bureacracy. I truely wonder how "breaking" that change is in the real world.
stamboom.BertKoor.nl runs on webtrees v1.7.13

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 4 hours ago #11

One "feature" of GEDCOM 7 is that the maximum length of an XREF has been removed. In version 5.5, it was 20 characters.


So, to support GEDCOM 7.0, we must move away from XREFs, and develop our own system for identifiers, URLs, etc.


Perhaps Iam misunderstanding something, but I guess, that every aplication generating a GEDCOM will have an own maximum length for XREFs.

It is only a mater of the import - when the XREF is smaler than my limit, than OK, when not - I have to rename the XREF to a shorter one.

But the idea of an other identifier which will be used in URLs is not bad. It would be helpful for the "roundtripper".


Ladislav
webtrees 2.0.16 + ⚶ Vesta modules (from cissee.de/)
on PHP Version 7.3.14

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 1 week 2 hours ago #12

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2065
Rola said:

Perhaps Iam misunderstanding something, but I guess, that every aplication generating a GEDCOM will have an own maximum length for XREFs.

True, but in most cases these application don’t care about the max length of the XREF, the code they have today will not change because most of them don’t expect their customers (users) to have more a few thousand individuals or maybe 100,000 photos. A 20 character pointer would hold trillions of items before running out of numbers and no PC or Mac database could hold that much without running out of its own resources. Besides, the XREF can also hold letters and then the number of unique IDs jumps even higher.

So my perception is that internally the contributors to this “bad design” don’t really care why they want an unlimited size, because they know that they already use either the 20 character max in v5.5 or something less and they have no need to change it because their software will never get to that many XREF IDs before the heads of their clients exploded when they run out of desire to work on their genealogy after the user finds a few 100 relatives and adds a few thousand photos.

The only people who would think they need an unlimited number of IDs would be Ancestry.com or LDS who without real though (or brains) want to cover all possibilities in the future and think an unlimited size string makes sense. Of course a 20 character (or even a 39 character) guid has a very large number of unique values, so many that I think they (I can’t myself) could not wrap their minds around the need for that many objects of any kind in their database.
Ken

Please Log in or Create an account to join the conversation.

Last edit: by norwegian_sardines.

GEDCOM 7.0.0 6 days 23 hours ago #13

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
Since unlimited length XREFs are available, I can easily see that systems will use them.

For example, it might use UUIDs for everything internally, and encode all sorts of meta-data as part of the XREF.

e.g. something like this would allow an exported record to be traced back to an export-event in the source system.

@indi:UUID,user:UUID,version:UUID,timestamp:UUID,....@

It has been decided - so if we want to support GEDCOM 7, then we need to live with this decision.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 23 hours ago #14

  • Sir Peter
  • Sir Peter's Avatar
  • Offline
  • Junior Member
  • Junior Member
  • Posts: 188
Sorry to be frank, but what they did with GEDCOM 7 I like to call fix-breaking something that didn't need a fix in the first place and I don't see its value because they missed to tackle several major issues. Instead they introduced unlimited XREFs and defined a new file extension .gdz instead of simply reusing .zip. What a breakthrough... I suggest the webtrees community stays with GEDCOM 5.5.1 as long as possible. As long as there are no applications that require GEDCOM 7 for an import/export there is no need to hurry. Maybe this will turn out as a stillborn anyway.

In the meantime the webtrees community could Sorry again for ranting.
Peter

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 23 hours ago #15

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
There is a similar issue that I also reported against the pre-release version.

Media files are to be stored in the root of the ZIP file.
The GEDCOM file should be stored in the root of the ZIP file with the name "gedcom.ged".

...so if you have a media file called "gedcom.ged" (I have several GEDCOM files as media files), then the filenames will clash.

I suggested that media be stored in a named subfolder, which would also free up the root folder for other designated files.

This change is also not backwards compatible, and I expect will be similarly rejected.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 23 hours ago #16

  • Sir Peter
  • Sir Peter's Avatar
  • Offline
  • Junior Member
  • Junior Member
  • Posts: 188

It has been decided - so if we want to support GEDCOM 7, then we need to live with this decision.


Would that become something like a blockchain thing?

The XREFs have no right to survive an import. Why put valuable information there? That's what they have been telling us all the time.
Peter

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 22 hours ago #17

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
> Why put valuable information there?

I'm just trying to guess ways in which applications might generate lengthy XREFs.

An even worse example might be an application which encodes additional data in the XREF.

This way, it could export a valid GEDCOM *and* also include data that only it could understand.

It would be able to say "Hey - our exports are valid GEDCOM" - but only their application would be able to read it.

e.g. this is a valid XREF.

0 @I123:birth-date=01-jan-1900:birth-place=london,england@
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 22 hours ago #18

  • Sir Peter
  • Sir Peter's Avatar
  • Offline
  • Junior Member
  • Junior Member
  • Posts: 188
I appreciate you thinking ahead, but let's cross that bridge once we get there. Such applications would be violating the overall idea behind an open and transparent data exchange format. And even worse they could change their data at any time without notice. The webtrees developer community would become the hare in Grimm's The Hare and the Hedgehog .
Peter

Please Log in or Create an account to join the conversation.

GEDCOM 7.0.0 6 days 22 hours ago #19

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2065
Greg Said:

It would be able to say "Hey - our exports are valid GEDCOM" - but only their application would be able to read it.

e.g. this is a valid XREF.

0 @I123:birth-date=01-jan-1900:birth-place=london,england@

And of course to take that statement to its logical extreme, a Source_Record XREF could contain all of the citation information normally found in each subtag of the record instance so that they did not have to parse out the real tags or invent new tags to support their own concept of a citation. Not having to actually retrieve the Source_Record to obtain all of the data within it would speed up some PC based applications.

GEDCOM v7 left a lot of open ended usage when they allow user defined custom facts (i.e. _xxxx) which on the surface works with their requirement that the fact gets defined on the generator's website, but in practice Family Search should have been the repository and clearing house of all custom fact so that companies don't reinvent tags that already existed by other software companies or caused collisions with tag names that are depended on context.

Historically GEDCOM was a major compromise between various factions, some wanted more meat and definition while others wanted to stay open ended and less committal. I think this version of GEDCOM continues that process.

They did not think about:
  • NAME tag
  • PLAC tag
  • Shared Facts
  • Add facts that every software company uses
  • Add tags in Source_Record to support more data
  • Add Ways to support enumerations in the file that can be reused from fact to fact.

They did add ASSO to facts (a good thing) and made some attempt at getting rid of some tag value "text" (incorporating an enumeration) but should have gone further! I'm still digesting the changes, but a lot of the comparisons I've looked at did not change a whole lot.
Ken

Please Log in or Create an account to join the conversation.

Last edit: by norwegian_sardines.

GEDCOM 7.0.0 6 days 22 hours ago #20

  • fisharebest
  • fisharebest's Avatar Topic Author
  • Offline
  • Administrator
  • Administrator
  • Posts: 14636
If I remember correctly, Microsoft was compelled by the courts to save documents in an "OpenOffice" format.

So they took exactly this approach. The exported files were completely valid - but critical formatting codes were embedded in comments.

This way, Microsoft could claim to be compatible with OpenOffice - but only Microsoft products could read these files.

I'm sure we can all think of large genealogy websites that would use underhand tricks like this to lock you in to their own ecosystem...
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

  • Page:
  • 1
  • 2
Powered by Kunena Forum