Family Historian User Group

[request withdrawn]

ID:4195

The problem is if that is done the app will not create 5.5 valid gedcom.

This has be argued at length previously.

[message withdrawn]

[message withdrawn]

[message withdrawn]

_NOTE is valid gedcom 5.5 at it's an program extension.

Is your request not covered by
Full use of RESN tag (update of FH to use proposed 5.5.1 Standard)

http://www.fhug.org.uk/wishlist/wldispl ... lwlref=189

You could just add a note to that one.

[message withdrawn]

Presumably there's a misprint on page 37 of 'THE GEDCOM STANDARD - DRAFT Release 5.5.1' [ged551-5.pdf] where I can see no mention of a > as a subordinate of the MULTIMEDIA_LINK.  Or is there a different downloadable document which is more complete?

[message withdrawn]

If FH makes such a great song and dance about being 100% Gedcom 5.5 compatible that if it does not support BLOBs in multimedia records then it is breaking the trade description act as it's compatibility is only 99% at best.

I think that 100% Gedcom compatibility should be recognised as a non starter. If FH is 100% but other programs are not and data is lost in the transfer then the 100% might as well be 0%. The main issue is to ensure that different program's interpretations of the specification are handled on import/export. That's what Gedcom was designed for, not the as the format for primary storage.

Whatever format FH uses for it's own storage has nothing to do with how data is transfered between programs. Also, users are not that interested in how the data is stored so long as they can access it. If you think it important that your data is stored in Gedcom format do you also have the same concern about your letters and documents created by Microsoft Word.

[message withdrawn]

Anonymous said:
...this forum seems to put a high value on it's compatibility.

I agree with Jon. I don't care how you store it as long as it supports the functionality I need. The standard is needed for Import and Export, and I think the only way to handle that is to have 'Export to GenesReunited...' and the like on the menu. Preferably implemented by some sort of custom Import/Export template so I can define my own and/or tweak the 'standard' ones.

[message withdrawn]

Morning!

Perhaps the reason for what you said is not so much that this forum puts a high value on compatibility, but that Calico Pie does. And to an extent I can understand that... It's always been a selling point that FH is 100% Gedcom compatible, and some people will buy it because of that, even though they don't necessarily understand the implications.

Any wish list request that implies a breach of the 'standard' is going to attract the comment that they ain't going to do it for that very reason, regardless of the functional requirement. That doesn't mean we shouldn't try... it all adds weight to the argument (which I think most people who do understand the implications would support) that (as Jon said elsewhere) 100% compliance is a non-starter, and that Calico Pie need to rethink what they're trying to achieve in this respect.

[message withdrawn]

Chris Bowyer said:
Any wish list request that implies a breach of the 'standard' is going to attract the comment that they ain't going to do it for that very reason, regardless of the functional requirement. That doesn't mean we shouldn't try... it all adds weight to the argument (which I think most people who do understand the implications would support) that (as Jon said elsewhere) 100% compliance is a non-starter, and that Calico Pie need to rethink what they're trying to achieve in this respect.

I do agree that the standard needs to be expanded to allow the various really important (in my opinion) things that are needed such as allowing formatting and tables in multi-line text fields (notes, sources, etc.) and places as entities in their own right. However, for me it is vital that there changes are documented for those of us who develop utilities. At least when it is based on GEDCOM I can easily find references to the format on the web. Unfortunately it often takes a lot of trial and error to work out how the additional tags that Calico have added work. As the developer of the popular Gedcom Census utility I don't get any prior warning from Calico of changes to the FH GEDCOM structure (e.g. when the relative paths were introduced), I have to find these out for myself (though Simon does answer any questions I email him about them). The more that Family Historian moves away from standard GEDCOM, the more difficult it makes developing these add-ons unless any GEDCOM changes are documented.

[message withdrawn]

Anonymous said:
Unless you use an Open Source application it's a fact of life that the technical documentation will more often than not be a trade secret.

Exactly the point I'm making. If it was a trade secret then I wouldn't have been able to develop Gedcom Census. If moving away from GECOM means that the formats become a 'trade secret' then all the various people who have said that Gedcom Census is one of the reasons they use FH would be disappointed at no longer being able to use it.

I'm not quite sure why you're bothering to argue with me on this. I agree that the GEDCOM standard needs to be expanded, all I am saying is that Calico Pie need to make sure they are keeping this standard open by documenting it. Surely you can't disagree with that?

[message withdrawn]