How abt GEDCOM 5.5.5? Considering to change/revise assess.ged? Torleif Haugødegård TMG user in Norway since 1995 -----Opprinnelig melding----- Fra: John Cardinal <[email protected]> Sendt: onsdag 4. desember 2019 22.37 Til: TMG-L <[email protected]>; [email protected] Emne: [Refugees]GEDCOM Assessment TMG and GEDCOM users, You may be interested to review a new facility, "GEDCOM Assessments". It began as structured way to evaluate how to configure TMG to GEDCOM for target applications. It grew into a separate, general-purpose facility for assessing the GEDCOM import capability of any target program or service. See: https://www.gedcomassessment.com The key component of GEDCOM Assessment is "assess.ged", a hand-crafted GEDCOM file. It's only been available a few days, and I have already heard from three software publishers who have used assess.ged to discover errors or omissions in their import methods. End users who have reason to use GEDCOM files should scan the "Assessment Review" for the application(s) they use. See: https://www.gedcomassessment.com/en/contents.htm#assessments John Cardinal Author of genealogy programs including Second Site, TMG Utility, GedSite, Gedcom Publisher, and TMG to GEDCOM _______________________________________________ Email preferences: http://bit.ly/rootswebpref Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 Rootsweb Blog: http://rootsweb.blog RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community

On 12/6/19 5:12 AM, torleif haugødegård wrote: > How abt GEDCOM 5.5.5? > Considering to change/revise assess.ged? > > Torleif Haugødegård > TMG user in Norway since 1995 > > The GEDCOM 5.5.5 that I think you are refering to is (to my understanding) an unofficial release by a single person, without any authorization by the owners of the GEDCOM standard, and currently has no industry backing. While it fixes some of the things that were problematic with the GEDCOM 5.5.1 document, it also breaks other things due to the person personal bias on what GEDCOM should be. The TSC group which is working on a formal definition of an interchange format, that includes a GEDCOM compatibility mode has decided to just ignore this so called standard and not try to include it as part of its interoperability definition. -- Richard Damon

Richard Damon wrote: > The GEDCOM 5.5.5 that I think you are refering to is (to my > understanding) an unofficial release by a single person, Richard, The document included multiple reviews, but Tamura Jones holds the copyright, so I think you are right it was primarily the work of one author. That's not necessarily a bad thing. > without any authorization by the owners of the GEDCOM standard The LDS has abandoned the GEDCOM standard (formally or not doesn't matter) and its unlikely they will authorize any one else to produce an official release. The hard part about uniting on an update to that standard is not whether it can include "GEDCOM" in the name, though I doubt the LDS will fight that. The hard part is getting the US/CAN/UK players to get behind it. I produced GEDCOM 5.5.2 and worked behind the scenes to get it adopted. I had a few comments from interested parties, but the main players in the US/CAN/UK market ignored it. See: https://jfcardinal.github.io/GEDCOM-5.5.2/gedcom-5.5.2.html I far prefer my 5.5.2 proposal over GEDCOM 5.5.5. There are a lot of similarities, but 5.5.5 has some curious and unnecessary inclusions. A pet peeve of mine is that it is delivered in a hard-to-use PDF. This is 2019, almost 2020. Standards should be online and in HTML. > and currently has no industry backing. I believe that's true and it's the key part. > While it fixes some of the things that were problematic with > the GEDCOM 5.5.1 document, it also breaks other things due to > the person personal bias on what GEDCOM should be. I read the 5.5.5 spec pretty carefully. I didn't see anything that would be hard to implement or would "break things". I didn't agree with several things, including a couple that I thought would put people off. Regarding breaking things, can you give an example? > The TSC group which is working on a formal definition of an > interchange format, that includes a GEDCOM compatibility mode has > decided to just ignore this so called standard and not try to > include it as part of its interoperability definition. Does TSC have any industry backing? From what I have read, TSC is going much deeper than 5.5.2 or 5.5.5 attempted. My efforts, at least, were focused on fixing some of the broken and ambiguous elements of the GEDCOM 5.5.1 spec. I believe we have to get software authors to agree on a GEDCOM standard before there is any hope of implementing a better, replacement transfer standard. The TSC effort is a separate effort, really. John

On 12/6/19 9:49 AM, John Cardinal wrote: > Richard Damon wrote: >> The GEDCOM 5.5.5 that I think you are refering to is (to my >> understanding) an unofficial release by a single person, > Richard, The document included multiple reviews, but Tamura Jones > holds the copyright, so I think you are right it was primarily the > work of one author. That's not necessarily a bad thing. Tamura Jones appears to have created a site called gedcom.org that CLAIMS to be 'This website is the official home of the GEDCOM specification.', which unless the LDS church has actually assigned such rights is an outright lie, and my understanding of the current domain name rules the LDS church could probably initiate a take-down order for the whole site (and domain name). The REAL official site for GEDCOM is https://www.familysearch.org/developers/docs/gedcom/ There are other groups/people working on successor 'standard' formats, and in general they tend to acknowledge that GEDCOM is 'owned' by the LDS, and come up with their own name,  >> without any authorization by the owners of the GEDCOM standard > The LDS has abandoned the GEDCOM standard (formally or not doesn't > matter) and its unlikely they will authorize any one else to produce > an official release. The hard part about uniting on an update to that > standard is not whether it can include "GEDCOM" in the name, though I > doubt the LDS will fight that. The hard part is getting the US/CAN/UK > players to get behind it. I produced GEDCOM 5.5.2 and worked behind > the scenes to get it adopted. I had a few comments from interested > parties, but the main players in the US/CAN/UK market ignored it. See: > https://jfcardinal.github.io/GEDCOM-5.5.2/gedcom-5.5.2.html I far > prefer my 5.5.2 proposal over GEDCOM 5.5.5. There are a lot of > similarities, but 5.5.5 has some curious and unnecessary inclusions. A > pet peeve of mine is that it is delivered in a hard-to-use PDF. This > is 2019, almost 2020. Standards should be online and in HTML. >> and currently has no industry backing. > I believe that's true and it's the key part. >> While it fixes some of the things that were problematic with the >> GEDCOM 5.5.1 document, it also breaks other things due to the person >> personal bias on what GEDCOM should be. > I read the 5.5.5 spec pretty carefully. I didn't see anything that > would be hard to implement or would "break things". I didn't agree > with several things, including a couple that I thought would put > people off. Regarding breaking things, can you give an example? From the discussion in the TSC group, it appears that due to some of the added restrictions in 5.5.5 that some data structures that have been used in 5.5.1 are specifically prohibited, and there isn't a clear path forward to implement them. One big issue is that the 'standard' insists that programs that read a 5.5.5 Gedcom must REJECT a file that doesn't fully conform to the spec, and isn't allowed to make a best effort to understand it. It prohibits the using of predefined tags in spots not specifically defined, creating a variant of a standard tag by adding a _ in front of it (tags with _ in front are specifically reserved for extensions, but can not be an existing tag with just a _ added in front, which breaks a lot of currently agreed upon extensions) and you can not create an extension tag that duplicates an existing defined tag (apparently even to use in a spot the original tag isn't allowed). One example given was that HEAD.NOTE doesn't specifically allow CONC/CONT, but it is commonly considered an acceptable extension to allow it, but by the Tamura Jones 5.5.5 a file that does that MUST be rejected, and it appears to be no easy way to define such a capability without running afoul of those rules. >> The TSC group which is working on a formal definition of an >> interchange format, that includes a GEDCOM compatibility mode has >> decided to just ignore this so called standard and not try to include >> it as part of its interoperability definition. > Does TSC have any industry backing? >From what I have read, TSC is > going much deeper than 5.5.2 or 5.5.5 attempted. My efforts, at least, > were focused on fixing some of the broken and ambiguous elements of > the GEDCOM 5.5.1 spec. I believe we have to get software authors to > agree on a GEDCOM standard before there is any hope of implementing a > better, replacement transfer standard. The TSC effort is a separate > effort, really. > John FHISO, the group that TSC works under does have some industry backing, including Ancestry.org, Rootsmagic, the FGS, and FFHS (or at least they were involved at the start, I don't follow it close enough to know how active they still are with the organization). And yes, it appears that their long term goal is something much bigger, but they are also working on a 'legacy' format that is basically GEDCOM with some cleanup and improved definition. -- Richard Damon

Richard, Tamura Jones took a different approach with 5.5.5 than I did with 5.5.2. I was trying to get software authors to agree on a modified GEDCOM 5.5.1 where most of the (relatively few) changes were limiting the spec to things that programs could already do. For example, my GEDCOM 5.5.2 was limited to UTF-8 only. That simplifies life for GEDCOM readers and writers. I also clarified the parsing rules, another attempt to make it easier to write conforming software. Regarding HEAD.NOTE, GEDCOM 5.5.1 allows CONT and CONC under HEAD.NOTE (pg 23-24, 2 OCT 1999 version of the draft). In my GEDCOM 5.5.2, I allowed CONT and CONC everywhere except for HEAD.CHAR and HEAD.GEDC.VERS. Those two limitations were stipulated solely to make it easier for "preview" components to verify the version and character encoding before starting up a full reader that supports CONT and CONC. I'll have to get over my aversion to reading PDF documents online and re-read GEDCOM 5.5.5. John

On 12/7/19 4:39 PM, John Cardinal wrote: > Richard, > > Tamura Jones took a different approach with 5.5.5 than I did with 5.5.2. I was trying to get software authors to agree on a modified GEDCOM 5.5.1 where most of the (relatively few) changes were limiting the spec to things that programs could already do. For example, my GEDCOM 5.5.2 was limited to UTF-8 only. That simplifies life for GEDCOM readers and writers. I also clarified the parsing rules, another attempt to make it easier to write conforming software. > > Regarding HEAD.NOTE, GEDCOM 5.5.1 allows CONT and CONC under HEAD.NOTE (pg 23-24, 2 OCT 1999 version of the draft). In my GEDCOM 5.5.2, I allowed CONT and CONC everywhere except for HEAD.CHAR and HEAD.GEDC.VERS. Those two limitations were stipulated solely to make it easier for "preview" components to verify the version and character encoding before starting up a full reader that supports CONT and CONC. > > I'll have to get over my aversion to reading PDF documents online and re-read GEDCOM 5.5.5. > > John I may have mis-read the comment from the TSC list about HEAD.NOTE and CONT (I grabbed a simple example given from a list of complaints give), it looks like that is allowed in 5.5.1 but has been explicitly forbidden in 5.5.5 due to the following section: CONC & CONT Restriction The GEDCOM specification allows CONC & CONT anywhere they are needed. GEDCOM 5.5.5 introduces a restriction, that should have been part of GEDCOM from the beginning, to keep parsing GEDCOM files simple; CONC & CONT must not be used with basic GEDCOM records, only with records defined by a GEDCOM form. It is illegal to use CONC or CONT within the Basic GEDCOM header. It is legal, but strongly discommended, to use CONC or CONT within a form-specific header extension. It is important to keep the GEDCOM header simple. The GEDCOM header is not only examined by GEDCOM readers, but also by general utilities that report file types. HEAD.DATE.COPR and HEAD.NOTE To avoid needing CONC & CONT with header subrecords of the Lineage-Linked Form, the maximum length of the HEAD.DATE.COPR and HEAD.NOTE lines values have both been set at 248 code units. The 248 code units allowed for <COPYRIGHT_GEDCOM_FILE> is significantly more than the maximum of 90 code units allowed by GEDCOM 5.4 and 5.5. The 248 code units allowed for <GEDCOM_CONTENT_DESCRIPTION> is more than the maximum 213 code units allowed by GEDCOM 5.4, and identical to the maximum of 248 code units allowed by GEDCOM 5.5. This seems to be a bit of a sample of the 'improvements' that Tamura Jones decided was needed, where practices she didn't think were good uses were just prohibited. -- Richard Damon

Torleif, If GEDCOM 5.5.5 gains acceptance and is implemented by any of the popular programs, I'll consider adding support for it in assess.ged. John