Rewriting the GEDCOM export for 3.0

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Rewriting the GEDCOM export for 3.0

Don Allingham
I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
making a few changes. These include:

1) Dropping trying to match the oddities of each program's
   interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
2) Reduce the number of options. Provide a "restrict data on living"
   option without the sub options. Assume that restring means restrict.

General questions:

1) Is it okay to export using UTF-8 only? Can all programs import UTF-8?
   ANSEL is a disaster, and I would rather not support it.

2) How do we handle exporting images? Using full paths or even relative
   paths makes moving to a different platform awkward. As one solution,
   I was thinking about allow writing a zip file that contains all the
   images and the gedcom file, making it easy to move to a different
   machine. But how do we handle the other cases?

3) Do we care about supplying a wide range of copyright notices in the
   file? Or should we just add a standard copyright message to all
   GEDCOM files?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Jim Winfrey
On 8/3/07, Don Allingham <[hidden email]> wrote:
> I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
> making a few changes. These include:
>
> 1) Dropping trying to match the oddities of each program's
>    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.

This is a good position if you intend to fully support Gedcom 5.5
compliant information and will put non-compliant information someplace
where it is not lost.  A strictly 5.5 compliance limits how some data
can be shown.

> 2) Reduce the number of options. Provide a "restrict data on living"
>    option without the sub options. Assume that restring means restrict.
>
> General questions:
>
> 1) Is it okay to export using UTF-8 only? Can all programs import UTF-8?
>    ANSEL is a disaster, and I would rather not support it.

This one has my vote as long as the UTF-8 format is faithfully used.
Some programs take as much liberty with UTF-8 as they do with Gedcom.
When I import files that were created in older versions of Reunion,
the UTF-8 setup strings are missing.

>
> 2) How do we handle exporting images? Using full paths or even relative
>    paths makes moving to a different platform awkward. As one solution,
>    I was thinking about allow writing a zip file that contains all the
>    images and the gedcom file, making it easy to move to a different
>    machine. But how do we handle the other cases?

I started out wondering why we would need this and then I thought
through how I move this dta between machines and finally decided this
is a great tool.  It automates what we do manually with the add that
it moves only the media that is actually used.
>
> 3) Do we care about supplying a wide range of copyright notices in the
>    file? Or should we just add a standard copyright message to all
>    GEDCOM files?
>

Jim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Don Allingham
On Fri, 2007-08-03 at 08:36 -0400, Jim Winfrey wrote:

> On 8/3/07, Don Allingham <[hidden email]> wrote:
> > I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
> > making a few changes. These include:
> >
> > 1) Dropping trying to match the oddities of each program's
> >    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
>
> This is a good position if you intend to fully support Gedcom 5.5
> compliant information and will put non-compliant information someplace
> where it is not lost.  A strictly 5.5 compliance limits how some data
> can be shown.

Well, I think the real problem is how it can get imported. Generating a
bunch of extra data that no tool can import doesn't do anything for
anyone. That is the problem with a lot of these GEDCOM files that we
see. They export extra stuff in custom extensions, and no other program
knows what to do with it.

>
> > 2) Reduce the number of options. Provide a "restrict data on living"
> >    option without the sub options. Assume that restring means restrict.
> >
> > General questions:
> >
> > 1) Is it okay to export using UTF-8 only? Can all programs import UTF-8?
> >    ANSEL is a disaster, and I would rather not support it.
>
> This one has my vote as long as the UTF-8 format is faithfully used.
> Some programs take as much liberty with UTF-8 as they do with Gedcom.
> When I import files that were created in older versions of Reunion,
> the UTF-8 setup strings are missing.

Do we know of any modern genealogy programs that do not import UTF-8?
The GEDCOM 5.5 spec states that the end goal is to switch to UTF-8. From
Chapter 3 (Using Character Sets in GEDCOM):

  UNICODE character set should be used for multi-language support as
  soon as operating systems begin providing adequate storage and display
  support


Thanks for the comments.

Don


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Duncan Lithgow-2
In reply to this post by Don Allingham
On Thu, 2007-08-02 at 22:13 -0600, Don Allingham wrote:
> I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
> making a few changes. These include:
>
> 1) Dropping trying to match the oddities of each program's
>    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
Does that mean dropping the work you've (plural) already done? Why not
just leave it - is it causing trouble?

...and extra information inside gramps must somehow be stored in the
gedcom. As notes is fine for me, as long as it is there to be seen. I'd
even accept/suggest it as plain text GRAMPS XML strings in the notes
(something I explained poorly one earlier time).

> 2) Reduce the number of options. Provide a "restrict data on living"
>    option without the sub options. Assume that restring means restrict.
I just had a look at the options and would like one other kept; "Do not
include records marked private"

> General questions:
>
> 1) Is it okay to export using UTF-8 only? Can all programs import UTF-8?
>    ANSEL is a disaster, and I would rather not support it.
I've never had trouble exchanging the gramps gedcoms

> 2) How do we handle exporting images? Using full paths or even relative
>    paths makes moving to a different platform awkward. As one solution,
>    I was thinking about allow writing a zip file that contains all the
>    images and the gedcom file, making it easy to move to a different
>    machine. But how do we handle the other cases?
I suggest we ignore all the complex solutions and go with the archived
directory option.

Can I however ask for a favour? I was planning on finally learning
Python so I could implement something like this. Part of my plan
involved storing the images in a logical directory structure, such as:

./GEDCOM-Archive
./GEDCOM-Archive/gedcom-file.ged
./GEDCOM-Archive/media-people/
./GEDCOM-Archive/media-family/
./GEDCOM-Archive/media-events/
./GEDCOM-Archive/media-sources/
./GEDCOM-Archive/media-places/

.. I understand this introduces some new problems like should we have
multiple copies of images connected to people _and_ events? Etc. So I'm
not saying we should do this now, but it's something I want to look into
as a way to automatically export my entire database in a way which
improves the structure of attached media. I now have several thousand
media files, including scanned letters, photos of heirlooms, maps and so
on. The current tools in gramps don't help me keep them in any sensible
structure. So I'm planning to work on the 'M' in GRAMPS.

> 3) Do we care about supplying a wide range of copyright notices in the
>    file? Or should we just add a standard copyright message to all
>    GEDCOM files?
I think that to be fair to those who go to the trouble of avoiding
breaking copyright law, we need to do something. This is why I've
mentioned that we really need to have a way of attaching copyright
statements per media file. There are a lot of sources I have which I am
free to share but may not be used commercially, and some I can't even
share (because I shouldn't really have them).

Duncan


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Brian Matherly
In reply to this post by Don Allingham
I have a suggestion to improve the export of Media objects. We could convert the media to ascii art and include it directly in the GEDCOM file.

~Brian

----- Original Message ----
From: Don Allingham <[hidden email]>
To: gramps-devel <[hidden email]>
Sent: Thursday, August 2, 2007 11:13:19 PM
Subject: [Gramps-devel] Rewriting the GEDCOM export for 3.0

I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
making a few changes. These include:

1) Dropping trying to match the oddities of each program's
   interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
2) Reduce the number of options. Provide a "restrict data on living"
   option without the sub options. Assume that restring means restrict.

General questions:

1) Is it okay to export using UTF-8 only? Can all programs import UTF-8?
   ANSEL is a disaster, and I would rather not support it.

2) How do we handle exporting images? Using full paths or even relative
   paths makes moving to a different platform awkward. As one solution,
   I was thinking about allow writing a zip file that contains all the
   images and the gedcom file, making it easy to move to a different
   machine. But how do we handle the other cases?

3) Do we care about supplying a wide range of copyright notices in the
   file? Or should we just add a standard copyright message to all
   GEDCOM files?





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Duncan Lithgow-2
In reply to this post by Don Allingham

On Fri, 2007-08-03 at 07:03 -0600, Don Allingham wrote:

> On Fri, 2007-08-03 at 08:36 -0400, Jim Winfrey wrote:
> > On 8/3/07, Don Allingham <[hidden email]> wrote:
> > > I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
> > > making a few changes. These include:
> > >
> > > 1) Dropping trying to match the oddities of each program's
> > >    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
> >
> > This is a good position if you intend to fully support Gedcom 5.5
> > compliant information and will put non-compliant information someplace
> > where it is not lost.  A strictly 5.5 compliance limits how some data
> > can be shown.
>
> Well, I think the real problem is how it can get imported. Generating a
> bunch of extra data that no tool can import doesn't do anything for
> anyone. That is the problem with a lot of these GEDCOM files that we
> see. They export extra stuff in custom extensions, and no other program
> knows what to do with it.
So why not add it to NOTE fields as human readable text, either prose or
GRAMPS XML as I've brought up in another thread. Anything is better than
dropping it.

Duncan


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

jgsack
Duncan Lithgow wrote:

> On Fri, 2007-08-03 at 07:03 -0600, Don Allingham wrote:
>> On Fri, 2007-08-03 at 08:36 -0400, Jim Winfrey wrote:
>>> On 8/3/07, Don Allingham <[hidden email]> wrote:
>>>> I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
>>>> making a few changes. These include:
>>>>
>>>> 1) Dropping trying to match the oddities of each program's
>>>>    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
>>> This is a good position if you intend to fully support Gedcom 5.5
>>> compliant information and will put non-compliant information someplace
>>> where it is not lost.  A strictly 5.5 compliance limits how some data
>>> can be shown.
>> Well, I think the real problem is how it can get imported. Generating a
>> bunch of extra data that no tool can import doesn't do anything for
>> anyone. That is the problem with a lot of these GEDCOM files that we
>> see. They export extra stuff in custom extensions, and no other program
>> knows what to do with it.
> So why not add it to NOTE fields as human readable text, either prose or
> GRAMPS XML as I've brought up in another thread. Anything is better than
> dropping it.
>

I think there are two broad problems.

But first, let me state my assumption that gedcom as an
inter-application exchange format will be around for some time, and the
opinion that we must deal with associated interoperability issues to the
reasonable satisfaction of our users.

   As an aside, I believe we should be serious about evolving
   own XML as a serious candidate for a replacement format.


The two problem are export and import:

1) On export from Gramps, the question which arises is what to do with
data items that do not (closely) map to gedcom data items.

  By "closely", I mean that there is general agreement that no
  essential meaning is lost in the translation, _and_ that Gramps
  itself would import that gedcom back into the original database
  semantics (ie, it passes a "round-trip" test). Anything that
  meets this requirement is not a problem, since it just works.

- One could argue that since other apps won't generally "know" what to
do with Gramps-specific data, that it should be silently omitted from
the exported gedcom.

- One could complain that users should at least be informed that data
will be omitted; perhaps a report of omitted data should be made available.

- Including the information as extra annotations within the gedcom could
be argued as a best-effort attempt at both transmitting the data and
preserving the context, ie, association with related data (since NOTEs
are referenced by or included as components of the related data).

2) On import of foreign gedcom data into Gramps, the question is what
should be done with "custom" data tags (ie, leading underscore or
otherwise non-standard tokens) or even gedcom data items that Gramps
does not handle.

- Gramps can continue to generate output warnings to stdout, possibly
expanding this practice to include those items which are standand
gedcom, but not handled by Gramps. Furthermore, perhaps this concept
could be turned into a formal report for the user to view or print.

- It might be asked that Gramps try to accommodate the common
customizations of other popular genealogy applications (or errors).

 (IMO, that may be endless, and likely thankless; maybe impossible.)

- Pre-processors might be written for converting common customizations
as above into NOTEs (or "equivalent" gedcom) that Gramps can properly
accept during import. With some cleverness and effort, maybe an
interactive application could be written to allow the user to review and
perhaps even modify the pre-processing of troublesome data.

- - -
I suppose there is, in fact, a third problem: what about round-trips.
Possibly this is a "second-order" concern, but it probably should be
acknowledged.

3a) Gramps importing previously Gramps-exported gedcom data can possibly
be argued away as unimportant since a better native data format is
available. But OTOH, it may be worth asking about a Gramps-export that
another application imports and re-exports, for Gramps to import. In
that case, what should gramps do with it's own custom-exported data.

3b) Gramps exporting data traceable to an initial existence as foreign
application custom data. Maybe that pre-processing utility should have a
reverse-mode of operation to maximize interoperability.
- - -

I suspect my analysis here is incomplete, but maybe it's a start?

Regards,
..jim

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Douglas S. Blank

On Tue, January 8, 2008 7:04 pm, James G. Sack (jim) wrote:

> Duncan Lithgow wrote:
>> On Fri, 2007-08-03 at 07:03 -0600, Don Allingham wrote:
>>> On Fri, 2007-08-03 at 08:36 -0400, Jim Winfrey wrote:
>>>> On 8/3/07, Don Allingham <[hidden email]> wrote:
>>>>> I'm planning the reworking the GEDCOM export for 3.0. I'm planning on
>>>>> making a few changes. These include:
>>>>>
>>>>> 1) Dropping trying to match the oddities of each program's
>>>>>    interpretation of GEDCOM. Target only the GEDCOM 5.5 standard.
>>>> This is a good position if you intend to fully support Gedcom 5.5
>>>> compliant information and will put non-compliant information someplace
>>>> where it is not lost.  A strictly 5.5 compliance limits how some data
>>>> can be shown.
>>> Well, I think the real problem is how it can get imported. Generating a
>>> bunch of extra data that no tool can import doesn't do anything for
>>> anyone. That is the problem with a lot of these GEDCOM files that we
>>> see. They export extra stuff in custom extensions, and no other program
>>> knows what to do with it.
>> So why not add it to NOTE fields as human readable text, either prose or
>> GRAMPS XML as I've brought up in another thread. Anything is better than
>> dropping it.
>>
>
> I think there are two broad problems.
>
> But first, let me state my assumption that gedcom as an
> inter-application exchange format will be around for some time, and the
> opinion that we must deal with associated interoperability issues to the
> reasonable satisfaction of our users.
>
>    As an aside, I believe we should be serious about evolving
>    own XML as a serious candidate for a replacement format.
>
>
> The two problem are export and import:
>
> 1) On export from Gramps, the question which arises is what to do with
> data items that do not (closely) map to gedcom data items.
>
>   By "closely", I mean that there is general agreement that no
>   essential meaning is lost in the translation, _and_ that Gramps
>   itself would import that gedcom back into the original database
>   semantics (ie, it passes a "round-trip" test). Anything that
>   meets this requirement is not a problem, since it just works.
>
> - One could argue that since other apps won't generally "know" what to
> do with Gramps-specific data, that it should be silently omitted from
> the exported gedcom.
>
> - One could complain that users should at least be informed that data
> will be omitted; perhaps a report of omitted data should be made
> available.
>
> - Including the information as extra annotations within the gedcom could
> be argued as a best-effort attempt at both transmitting the data and
> preserving the context, ie, association with related data (since NOTEs
> are referenced by or included as components of the related data).
>
> 2) On import of foreign gedcom data into Gramps, the question is what
> should be done with "custom" data tags (ie, leading underscore or
> otherwise non-standard tokens) or even gedcom data items that Gramps
> does not handle.
>
> - Gramps can continue to generate output warnings to stdout, possibly
> expanding this practice to include those items which are standand
> gedcom, but not handled by Gramps. Furthermore, perhaps this concept
> could be turned into a formal report for the user to view or print.
>
> - It might be asked that Gramps try to accommodate the common
> customizations of other popular genealogy applications (or errors).
>
>  (IMO, that may be endless, and likely thankless; maybe impossible.)

Jim,

Thanks for the analysis: good starting points. I'll provide a personal
insight. For me, I think the most import single function in GRAMPS is the
GEDCOM import. If importing my GEDCOM data into GRAMPS had not worked, I'm
not sure I'd be here right now. It would have been too much to think about
re-entering the data.

In fact, when I attempted to import my data from a really old version of
FTM for Windows, circa 1995, it didn't quite work, but I added just a bit
of code, and I think that code was applied back into GRAMPS (my first
GRAMPS interactions).

I suspect that the old GEDCOM import code got really ugly with lots of
special cases. But, it was able to get people into GRAMPS. This may be
somewhat analogous to being able to read .DOC formats: it is an ugly,
possibly thankless, job but I think necessary.

I guess my suggestion would be to keep adapting the GEDCOM importer as
people need additional improvements to get their data into GRAMPS. If
there are ambiguous entries, it might be necessary for users to identify
the import variation. There is little use for new users to continually
have to re-invent the different parser variations. We should keep those in
a centralized place, and I think the importer is the right place.

I still think it would be a good idea to export all of GRAMPS in GEDCOM
somehow, but that is a minor issue compared to import.

My $.02,

-Doug

> - Pre-processors might be written for converting common customizations
> as above into NOTEs (or "equivalent" gedcom) that Gramps can properly
> accept during import. With some cleverness and effort, maybe an
> interactive application could be written to allow the user to review and
> perhaps even modify the pre-processing of troublesome data.
>
> - - -
> I suppose there is, in fact, a third problem: what about round-trips.
> Possibly this is a "second-order" concern, but it probably should be
> acknowledged.
>
> 3a) Gramps importing previously Gramps-exported gedcom data can possibly
> be argued away as unimportant since a better native data format is
> available. But OTOH, it may be worth asking about a Gramps-export that
> another application imports and re-exports, for Gramps to import. In
> that case, what should gramps do with it's own custom-exported data.
>
> 3b) Gramps exporting data traceable to an initial existence as foreign
> application custom data. Maybe that pre-processing utility should have a
> reverse-mode of operation to maximize interoperability.
> - - -
>
> I suspect my analysis here is incomplete, but maybe it's a start?
>
> Regards,
> ..jim


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Duncan Lithgow-2
In reply to this post by jgsack
On Tue, 2008-01-08 at 16:04 -0800, James G. Sack (jim) wrote:
> Duncan Lithgow wrote:
> > So why not add it to NOTE fields as human readable text, either prose or
> > GRAMPS XML as I've brought up in another thread. Anything is better than
> > dropping it.
> >
> The two problem are export and import:
I wouldn't even split it up like that. There is one problem as I see it.

We are throwing away data.

But yes, Jim, we are doing it in two ways:
1. We are ignoring and discarding anything we don't understand in
incoming GEDCOM files.
2. We are flinging out into the ether anything we have painstakingly
entered into GRAMPS which does not fit into the GEDCOM paradigm and
format.

I was really amazed when I first discovered this. So each time I have
sent a piece of my data to someone as a think you for their help I was
only sending them some of the work I have done!!??

> 1) On export from Gramps, the question which arises is what to do with
> data items that do not (closely) map to gedcom data items.
I think the round-trip test would be great - but not the first priority.
(an asside: But this was the reason I initially suggested exporting
GRAMPS XML segments in NOTe fields - I assume that would make
reintegration into GRAMPS easier...)

> - One could argue that since other apps won't generally "know" what to
> do with Gramps-specific data, that it should be silently omitted from
> the exported gedcom.
Ah, but if we used GRAMPS XML snippets they could easily look it up and
parse it better. Users might even start complaining to the software
makers that they should be able to do it better...

> - One could complain that users should at least be informed that data
> will be omitted; perhaps a report of omitted data should be made available.
A report? I suppose so, but what a nightmare connecting that report back
to the relevant data..

> - Including the information as extra annotations within the gedcom could
> be argued as a best-effort attempt at both transmitting the data and
> preserving the context, ie, association with related data (since NOTEs
> are referenced by or included as components of the related data).
>
> 2) On import of foreign gedcom data into Gramps, the question is what
> should be done with "custom" data tags (ie, leading underscore or
> otherwise non-standard tokens) or even gedcom data items that Gramps
> does not handle.
I would like GRAMPS to tell me what it's doing. I would like to be asked
during import what to do with the non-standard data. Most of the time I
would like it to go into the relevant note fields in GRAMPS with some
text explaining how it got there. (I've filed a feature request to this
effect: http://bugs.gramps-project.org/view.php?id=1571)

Then if I work out what something means and find a way to make it fit
into the GRAMPS paradigm I can talk to the devs and can start making a
parsing script. (Again round-trip is not _my_ priority here, data preservation _is_).
> - Gramps can continue to generate output warnings to stdout, possibly
> expanding this practice to include those items which are standand
> gedcom, but not handled by Gramps.
Are there some?



Duncan


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Dave Walton-3
Duncan Lithgow wrote:

> On Tue, 2008-01-08 at 16:04 -0800, James G. Sack (jim) wrote:
>> Duncan Lithgow wrote:
>>> So why not add it to NOTE fields as human readable text, either prose or
>>> GRAMPS XML as I've brought up in another thread. Anything is better than
>>> dropping it.
>>>
>> The two problem are export and import:
> I wouldn't even split it up like that. There is one problem as I see it.
>
> We are throwing away data.
>
> But yes, Jim, we are doing it in two ways:
> 1. We are ignoring and discarding anything we don't understand in
> incoming GEDCOM files.
> 2. We are flinging out into the ether anything we have painstakingly
> entered into GRAMPS which does not fit into the GEDCOM paradigm and
> format.

I agree strongly that the top priority should be preserving all data on
import or export.  If there's no clear place to put it other than as
human-readable text in a note, so be it.  Better plain text than gone
entirely.

> I would like GRAMPS to tell me what it's doing. I would like to be asked
> during import what to do with the non-standard data. Most of the time I
> would like it to go into the relevant note fields in GRAMPS with some
> text explaining how it got there. (I've filed a feature request to this
> effect: http://bugs.gramps-project.org/view.php?id=1571)

Excellent!  Is there an equivalent feature request filed for the export
side of the coin?  I don't see one.  Or perhaps that's been done already?

Dave



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rewriting the GEDCOM export for 3.0

Raphael Ackermann
On Feb 3, 2008 8:30 PM, Dave Walton <[hidden email]> wrote:
>
> > I would like GRAMPS to tell me what it's doing. I would like to be asked
> > during import what to do with the non-standard data. Most of the time I
> > would like it to go into the relevant note fields in GRAMPS with some
> > text explaining how it got there. (I've filed a feature request to this
> > effect: http://bugs.gramps-project.org/view.php?id=1571)
>
> Excellent!  Is there an equivalent feature request filed for the export
> side of the coin?  I don't see one.  Or perhaps that's been done already?

I've just filed two feature requests regarding this
http://bugs.gramps-project.org/view.php?id=1720 : general discussion
about how not to throw away data on import/export
http://bugs.gramps-project.org/view.php?id=1727 : export to gedcom

I've added comments from the mailing list on the issues.

Raphael

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel