TMG-L Archives

Archiver > TMG > 2003-01 > 1041436984


From: Richard Cleaveland <>
Subject: Re: [TMG] GEDCOM export missing county
Date: Wed, 01 Jan 2003 11:03:04 -0500
References: <000901c2b02a$b3e15800$6401a8c0@charliexii><5.2.0.9.2.20021230105941.01638b48@mail.richard.cleaveland.name><001401c2b018$1a04efb0$6401a8c0@charliexii> <3E0E3DBE.73DFFFAF@sbcglobal.net><5.2.0.9.2.20021230071337.014be4c0@mail.richard.cleaveland.name><5.2.0.9.2.20021230105941.01638b48@mail.richard.cleaveland.name><5.2.0.9.2.20021230122121.0168b4d8@mail.richard.cleaveland.name><5.2.0.9.2.20030101092523.017b1a90@mail.richard.cleaveland.name>
In-Reply-To: <3E1302EC.3020905@reigelridge.com>


At 10:02 AM 1/1/2003, Terry Reigel wrote:
>Richard Cleaveland wrote:
>
>>And until then* all the more reason for TMG to mark in some way those
>>data elements or tags which will not transfer via GEDCOM. <g><g>
>
>
>Dick,
>
>I know your comment was meant a bit tongue in cheek, but when I think
>about the idea of marking data which will not transfer, that seems to me
>to be an all but impossible task. First, of course, you need to decide
>whether you mean GEDCOM 4.0 or 5.5, or one of the three other versions,
>because the results differ somewhat.

As I previously suggested, I believe that covering only the most recent
version would be sufficient.

>After that, some cases are pretty easy to identify, like the county field
>in Repositories which you brought up. But others are not. Take you basic
>census tag -- when there are two principals, it gets exported if they are
>married, but not if they aren't.

So the "marking" would be dependent on the data. Not really rocket science.

> Do you really want TMG to take resources to check each tag in detail
> every time it's edited in order to make such a mark?

I can't comment on the programming resources; only the program manager can
do that. And certainly other activities to flesh out TMG5 to fully
operational status would and should take priority.

As far as operational resources - well, first, the feature could be an
option (I know, option checking takes some resources too) and secondly,
machines are getting faster and RAM-bigger rapidly, so the impact would
probably be minimal (compared, for instance, with the popular accent
feature). Some items, of course, could be "permanently" marked as they are
independent of the data (the county in repositories as an example) and
hence take no operational resources.

> Even if you did that, what would you want to do about information that
> TMG exports to GEDCOM that few or no other programs will read? That seems
> to me to be at least as big a hole as what doesn't get exported.

That's an issue to be taken up with the managers of those other
programs. I mentioned earlier here about Legacy incorrectly importing the
STAE element in the repository address. I reported that to them the same
day I discovered it. Later that day I got a response that it was being sent
to the programmer responsible. The next day I received a report from the
programmer that it had been fixed, thank you very much, and that the fix
would be in the next web posting. I have no information about the
management responsiveness of other GEDCOM importers to bug reports.

>I agree that the whole GEDCOM issue is ugly, but I'm not convinced there's
>much TMG can do about it that will gain very widespread support among users.

Yes, I know Bob has made great efforts in the past to have the "standard"
improved, and the UFT people even went overboard to try to leverage some
improvements, all to no avail. My suggestion was made in the spirit of
trying to make the best of a bad situation. As far as the gaining of
widespread support among TMG users I suspect you are right. Based on what I
see on this list and observe at RUG meetings and in off-list
communications, the majority of TMG users have little appreciation of the
myriad of features it offers.

Dick

This thread: