Quantcast

Wrongly posted to gramps-bugs...

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Wrongly posted to gramps-bugs...

Nick Wallingford-2
This was posted to gramps-bugs, but I am going to take the liberty of
reposting here instead, as it seems more an overall 'developer' issue
rather than a bug...

Nick
Tauranga NZ

============================================================


Subject:
Fwd: [Ancestors Now] New comment on Pandora's Box.
From: Tim Forsythe <[hidden email]>
Date: 03/01/12 01:43

fyi

---------- Forwarded message ----------
From: Tim Forsythe <[hidden email]>
Date: Mon, Jan 2, 2012 at 6:32 AM
Subject: [Ancestors Now] New comment on Pandora's Box.
To: [hidden email]

Tim Forsythe has left a new comment on your post "Pandora's Box":

I was asked to take a look at the free genealogy application, Gramps, to
see how it handled GEDCOM files. Being curious I did a quick test this
morning, with my GEDCOM file. The results were not good. I imported my
file into Gramps, exported it without any changes, and compared the
resulting files.

Here are a few of the major problems I found.

1. The resulting file was not GEDCOM compliant
2. All Multimedia records were thrown away (i.e. OBJE)
3. All user defined records were thrown away (i.e. _NNNN)
4. All embedded notes were converted to linked notes, which in itself is
not a problem, but they reused existing note record ids resulting in
duplicates, which no application could possibly use.
5. They wrapped all tag data at 80 characters using the CONT tag,
unfortunately, GEDCOM does not allow many records to be wrapped like the
CAUS and NAME tags, resulting in invalid record fields.
6. Social Security Number tags were thrown away.

The list goes on, but chances are if you tried to import this file into
another genealogy program you would get errors and lose data. I
reimported the file to Gramps, and as expected, due to duplicate note
ids, the wrong notes were linked to individuals, and important data was
missing. It did handle the invalid wrapping properly.



Posted by Tim Forsythe to Ancestors Now at January 2, 2012 6:32 AM

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

Benny Malengier
2012/1/2 Nick Wallingford <[hidden email]>:

> This was posted to gramps-bugs, but I am going to take the liberty of
> reposting here instead, as it seems more an overall 'developer' issue
> rather than a bug...
>
> Nick
> Tauranga NZ
>
> ============================================================
>
>
> Subject:
> Fwd: [Ancestors Now] New comment on Pandora's Box.
> From: Tim Forsythe <[hidden email]>
> Date: 03/01/12 01:43
>
> fyi
>
> ---------- Forwarded message ----------
> From: Tim Forsythe <[hidden email]>
> Date: Mon, Jan 2, 2012 at 6:32 AM
> Subject: [Ancestors Now] New comment on Pandora's Box.
> To: [hidden email]
>
> Tim Forsythe has left a new comment on your post "Pandora's Box":
>
> I was asked to take a look at the free genealogy application, Gramps, to
> see how it handled GEDCOM files. Being curious I did a quick test this
> morning, with my GEDCOM file. The results were not good. I imported my
> file into Gramps, exported it without any changes, and compared the
> resulting files.
>
> Here are a few of the major problems I found.
>
> 1. The resulting file was not GEDCOM compliant

This would be debatable for all programs out there. Anyway, no information given

> 2. All Multimedia records were thrown away (i.e. OBJE)

I assume the import did not find the media files, so did not import
them. You should try to import the Gedcom so that the multimedia is
present after import, by investigating this further.
I believe there is a bug ticket to import media records also when the
media is not found, eg because it links to an online repository
instead of a file on disk, which would be an improvement. So this bug
is known. If Gramps finds the multimedia, there should not be a
problem however.

> 3. All user defined records were thrown away (i.e. _NNNN)

User defined records don't sound like official GEDCOM, so it is normal
they are thrown away. An standard should also only contain standard
data on export.

> 4. All embedded notes were converted to linked notes, which in itself is
> not a problem, but they reused existing note record ids resulting in
> duplicates, which no application could possibly use.

As you noticed, in Gramps all notes are linked.
About the reuse of note ids, this seems like a serious bug. It should
be possible to fix by using the reorder gramps id tool in Gramps. If
you would like Gramps to improve, please start a bug ticket and an
example gedcom that shows this behavior.

> 5. They wrapped all tag data at 80 characters using the CONT tag,
> unfortunately, GEDCOM does not allow many records to be wrapped like the
> CAUS and NAME tags, resulting in invalid record fields.

The standard also talks about a maximum character count on a line. As
you note, this should not be a problem, many programs use the GEDCOM
standard like this.

> 6. Social Security Number tags were thrown away.

You mean the SSN tag I suppose. It should be in the attribute list in
Gramps, as import does take it into account
(http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/lib/libgedcom.py?revision=18691&view=markup
).
Reading the code, also export is taken care of.
SSN is part of a very ugly part in the GEDCOM standard, using event
details for factual data.
If SSN is lost, there must be a bug somewhere, or in the GEDCOM you
import, or in Gramps.

Benny

> The list goes on, but chances are if you tried to import this file into
> another genealogy program you would get errors and lose data. I
> reimported the file to Gramps, and as expected, due to duplicate note
> ids, the wrong notes were linked to individuals, and important data was
> missing. It did handle the invalid wrapping properly.
>
>
>
> Posted by Tim Forsythe to Ancestors Now at January 2, 2012 6:32 AM
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

jerome
Tim,

> I was using Gramps 3.3.1 (AIO v.2) the exported file has duplicate
> record ids so was not GEDCOM 5.5 or 5.5.1 compliant
> my GEDCOM  file is generated by Family Historian v3 and tested by VGed 3.02

Maybe I understand why you said 'compliant' ...
Family Historian makes some verifications on import as gedcom is used as its native file format.

Unfortunately, that is also why FH is noted as inconsistent, cause of flexibility for reading all types of content generated by all types of program: not compliant against gedcom 5.5 on header and encoding[1][2][3]. ;)

About the duplicated records ids, this looks very strange because Gramps does not use it as internal identifiant: they are imported, then exported.
Maybe these records were shared and written as multiple copies on import?
ie. they should be merged into Gramps or gedcom file format should support shared events, places (for CENS and others events). If so, the testing environment is far away to the reality, as most users will not export duplicated records as they are working with these data and we all want to share complete and consistent data. As said, like for media, this could be fixed by human checking by using batch tools! Most internal tools provided by Gramps have been generated for this type of action.

As you noted Gramps also made a mix on export using a part of the Gedcom 5.5.1 spec with the Gedcom 5.5 header... Like with FH, others programs should be still able to import the generated gedcom! ;)

As said by Benny, bug reports and feature requests are useful for improving the current code. The current gedcom file handling into Gramps seems not compliant, even I assume that default options for 'Kdiff3' is not the most accurate for testing lost data into imported/exported gedcoms! Why not a words/characters counter/list? Once syntax is valid, we should not force to use one way for exporting data, otherwise the file specification/template is maybe not complete or wrong!

About user defined tags that begin with an underscore, Gramps supports some of them and ignore some others. Link to 'libgedcom.py' given by Benny.

[1] http://ohmi.celeonet.fr/gedcom/8_Bilans/vPrologue.html
[2] http://ohmi.celeonet.fr/gedcom/7_Malus/zabar/70_Malus.pdf
[3] http://ohmi.celeonet.fr/gedcom/1_Header/zabar/13_BilanHeader.html


Thanks.
Jérôme

--- En date de : Mar 3.1.12, Benny Malengier <[hidden email]> a écrit :

> De: Benny Malengier <[hidden email]>
> Objet: Re: [Gramps-devel] Wrongly posted to gramps-bugs...
> À: "Nick Wallingford" <[hidden email]>, "Tim Forsythe" <[hidden email]>
> Cc: "Gramps developers" <[hidden email]>
> Date: Mardi 3 janvier 2012, 11h45
> 2012/1/2 Nick Wallingford <[hidden email]>:
> > This was posted to gramps-bugs, but I am going to take
> the liberty of
> > reposting here instead, as it seems more an overall
> 'developer' issue
> > rather than a bug...
> >
> > Nick
> > Tauranga NZ
> >
> >
> ============================================================
> >
> >
> > Subject:
> > Fwd: [Ancestors Now] New comment on Pandora's Box.
> > From: Tim Forsythe <[hidden email]>
> > Date: 03/01/12 01:43
> >
> > fyi
> >
> > ---------- Forwarded message ----------
> > From: Tim Forsythe <[hidden email]>
> > Date: Mon, Jan 2, 2012 at 6:32 AM
> > Subject: [Ancestors Now] New comment on Pandora's
> Box.
> > To: [hidden email]
> >
> > Tim Forsythe has left a new comment on your post
> "Pandora's Box":
> >
> > I was asked to take a look at the free genealogy
> application, Gramps, to
> > see how it handled GEDCOM files. Being curious I did a
> quick test this
> > morning, with my GEDCOM file. The results were not
> good. I imported my
> > file into Gramps, exported it without any changes, and
> compared the
> > resulting files.
> >
> > Here are a few of the major problems I found.
> >
> > 1. The resulting file was not GEDCOM compliant
>
> This would be debatable for all programs out there. Anyway,
> no information given
>
> > 2. All Multimedia records were thrown away (i.e.
> OBJE)
>
> I assume the import did not find the media files, so did
> not import
> them. You should try to import the Gedcom so that the
> multimedia is
> present after import, by investigating this further.
> I believe there is a bug ticket to import media records
> also when the
> media is not found, eg because it links to an online
> repository
> instead of a file on disk, which would be an improvement.
> So this bug
> is known. If Gramps finds the multimedia, there should not
> be a
> problem however.
>
> > 3. All user defined records were thrown away (i.e.
> _NNNN)
>
> User defined records don't sound like official GEDCOM, so
> it is normal
> they are thrown away. An standard should also only contain
> standard
> data on export.
>
> > 4. All embedded notes were converted to linked notes,
> which in itself is
> > not a problem, but they reused existing note record
> ids resulting in
> > duplicates, which no application could possibly use.
>
> As you noticed, in Gramps all notes are linked.
> About the reuse of note ids, this seems like a serious bug.
> It should
> be possible to fix by using the reorder gramps id tool in
> Gramps. If
> you would like Gramps to improve, please start a bug ticket
> and an
> example gedcom that shows this behavior.
>
> > 5. They wrapped all tag data at 80 characters using
> the CONT tag,
> > unfortunately, GEDCOM does not allow many records to
> be wrapped like the
> > CAUS and NAME tags, resulting in invalid record
> fields.
>
> The standard also talks about a maximum character count on
> a line. As
> you note, this should not be a problem, many programs use
> the GEDCOM
> standard like this.
>
> > 6. Social Security Number tags were thrown away.
>
> You mean the SSN tag I suppose. It should be in the
> attribute list in
> Gramps, as import does take it into account
> (http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/lib/libgedcom.py?revision=18691&view=markup
> ).
> Reading the code, also export is taken care of.
> SSN is part of a very ugly part in the GEDCOM standard,
> using event
> details for factual data.
> If SSN is lost, there must be a bug somewhere, or in the
> GEDCOM you
> import, or in Gramps.
>
> Benny
>
> > The list goes on, but chances are if you tried to
> import this file into
> > another genealogy program you would get errors and
> lose data. I
> > reimported the file to Gramps, and as expected, due to
> duplicate note
> > ids, the wrong notes were linked to individuals, and
> important data was
> > missing. It did handle the invalid wrapping properly.
> >
> >
> >
> > Posted by Tim Forsythe to Ancestors Now at January 2,
> 2012 6:32 AM
> >
> >
> ------------------------------------------------------------------------------
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you
> don't need a complex
> > infrastructure or vast IT resources to deliver
> seamless, secure access to
> > virtual desktops. With this all-in-one solution,
> easily deploy virtual
> > desktops for less than the cost of PCs and save 60% on
> VDI infrastructure
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Gramps-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app
> development. Create
> new or port existing apps to sell to consumers worldwide.
> Explore the
> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

DS Blank
In reply to this post by Nick Wallingford-2
> From: Tim Forsythe <[hidden email]>
> Date: Mon, Jan 2, 2012 at 6:32 AM
> Subject: [Ancestors Now] New comment on Pandora's Box.
> To: [hidden email]
>
> Tim Forsythe has left a new comment on your post "Pandora's Box":
>
> I was asked to take a look at the free genealogy application, Gramps, to
> see how it handled GEDCOM files. Being curious I did a quick test this
> morning, with my GEDCOM file. The results were not good. I imported my
> file into Gramps, exported it without any changes, and compared the
> resulting files.
>
> Here are a few of the major problems I found.
>
> 1. The resulting file was not GEDCOM compliant

Tim,

All known Gramps and GEDCOM differences are listed here:

http://www.gramps-project.org/wiki/index.php?title=Gramps_and_GEDCOM

If there is one thing that Gramps attempts to do right is be
GEDCOM-compliant, even if that means ignoring some standard, but
non-compliant, parts. After all, there are probably many competing
extensions---how would we decide which is more important? If you can
provide details on what you believe is non-compliant, that is the only
way we can fix the issue. You can even upload a GEDCOM to the tracker
and mark it private so that we can test. Or email it to a developer
for private testing.

> 2. All Multimedia records were thrown away (i.e. OBJE)

As Benny mentioned, there are a couple of possible issues. We are also
working on adding functionality on this point.

> 3. All user defined records were thrown away (i.e. _NNNN)

That is non-standard GEDCOM, right?

> 4. All embedded notes were converted to linked notes, which in itself is
> not a problem, but they reused existing note record ids resulting in
> duplicates, which no application could possibly use.

Are you sure about that? If so, definitely a bug, but we'd need an
example to track down the problem.

> 5. They wrapped all tag data at 80 characters using the CONT tag,
> unfortunately, GEDCOM does not allow many records to be wrapped like the
> CAUS and NAME tags, resulting in invalid record fields.

As far as we know, we produce valid GEDCOM. Could it be that your
other program is in error?

> 6. Social Security Number tags were thrown away.

Not likely. More likely is that the ended up as an attribute of the
person. But again, this is non-standard GEDCOM, right?

> The list goes on, but chances are if you tried to import this file into
> another genealogy program you would get errors and lose data.

Every program handles GEDCOM differently, but we can't help what other
programs do. We can only be as conformant as possible to the GEDCOM
standard.

> I
> reimported the file to Gramps, and as expected, due to duplicate note
> ids, the wrong notes were linked to individuals, and important data was
> missing. It did handle the invalid wrapping properly.

We take each issue seriously, and we have a well-defined process for
dealing with issues: each problem should be reported here:

http://www.gramps-project.org/bugs/main_page.php

For more information on issues, please see:

http://www.gramps-project.org/wiki/index.php?title=How_to_report_bugs

-Doug

> Posted by Tim Forsythe to Ancestors Now at January 2, 2012 6:32 AM

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

Benny Malengier
Thanks for the reply Tim.
With this mail, the rest of the list can read it too.

Greetings,
Benny

2012/1/3 Tim Forsythe <[hidden email]>:

> All,
>
> #1
> I tested both my original Family Historian GEDCOM file and the Gramps
> exported GEDCOM file in VGed
> (http://ancestorsnow.blogspot.com/2011/07/vged.html) to test GEDCOM
> compliance.  The Gramps exported file is non-compliant because there were
> duplicate NOTE record ids.  Also, the exported file also ended up with two
> empty* source records: "0 @@S2@@ SOUR" and "0 @@S417@@ SOUR" - not sure why
> only those two source records were corrupted.  Gramps did create '0 @S0002@
> SOUR' and '0 @S0417@ SOUR' correctly.
>
> * empty - included the CHAN record only.
>
> If you try to use VGed, it has a bug that I need to fix that sees records in
> the form: "2 DATE @#DJULIAN@ 1 JAN 2012" as an error.  Oops!
>
> #2
> My OBJE files have relative links, so Gramps will not be able to find them,
> hence the reason the records were dropped.  You've already addressed this as
> a known bug.
>
> #3
> User defined tags a defined as part of the GEDCOM grammer (not standard
> GEDCOM primitive elements).  so I would expect them to be parsed correctly,
> and then preferably saved, not thrown away.  My particular GEDCOM file makes
> heavy use of these.  All this data is being lost on import. Gramps could be
> saving the TAG name and data into a generic text field and allow both
> editing and exporting of them so the data is not lost, but it is not
> currently doing this.  This will effect anyone exporting non-standard data
> from other genealogy applications that save this data into user-defined tags
> as required by the GEDCOM standard.
>
> #4
> 7800 embedded notes in my GEDCOM file were converted to linked notes
> starting with N0000.  However, my GEDCOM file already had linked notes for
> N1 thru N115, so the exported file has duplicates for those 115 note
> records, i.e. N0000, N0001, N0001, N0002, N0002, ... N0115, N0115, N0116,
> N0117 ... N7800.   I would think you could test this easy enough by
> importing a file with 1 linked note in the form of '0 @N1@' and see if you
> end up with two '0 @N0001@' records on export.
>
> #5
> my bad, this is allowed behavior
>
> #6
> again my bad, it was there, just relocated so did not initially see it.
>
>
> Additional issues I saw were:
>
> #7 Repository records are no longer referenced by sources.
>
> #8 Some (or all - can't be sure) embedded notes that are fields of event
> (and presumably attribute) records are converted to linked notes, but then
> not referenced from the event records.
>
> #9 I have some user defined tags in my file in the form of '1 _FORCE now'
> that are converted to:
>
> 1 EVEN
> 2 TYPE
> 2 NOTE Description: now
>
> Also, GEDCOM 5.5 defines the EVEN record TYPE as:
>
> n  TYPE <EVENT_DESCRIPTOR>  {0:1}
>
> and
> EVENT_DESCRIPTOR: =  {Size=1:90}
>
> so the TYPE field should be missing or have a EVENT_DESCRIPTOR defined.
>
>
> -----
> Your website gave two options for reporting bugs, One is to signup and
> submit 'incident reports'.  The other was to just send an email w/o having
> to create an account, which seemed easier explaining why your group received
> the email blast.  Since I have not sighed up for an account, I am not able
> to respond back to the group, so you all are receiving this email
> individually.  You'll need to forward it to anyone else in your group
> interested.
>
> Tim Forsythe
>
> P.S. I am not a Gramps user.  I was asked to test the GEDCOM import/export
> facility for someone else who liked the program, and wanted to be able to
> import files from another application without losing data, presumably to
> make use of Gramps utility features like reporting and charts.  I have a
> blog where I sometimes discuss the ins and outs of this process.
>
>
>
>
>
> On Tue, Jan 3, 2012 at 7:59 AM, Doug Blank <[hidden email]> wrote:
>>
>> > From: Tim Forsythe <[hidden email]>
>> > Date: Mon, Jan 2, 2012 at 6:32 AM
>> > Subject: [Ancestors Now] New comment on Pandora's Box.
>> > To: [hidden email]
>> >
>> > Tim Forsythe has left a new comment on your post "Pandora's Box":
>> >
>> > I was asked to take a look at the free genealogy application, Gramps, to
>> > see how it handled GEDCOM files. Being curious I did a quick test this
>> > morning, with my GEDCOM file. The results were not good. I imported my
>> > file into Gramps, exported it without any changes, and compared the
>> > resulting files.
>> >
>> > Here are a few of the major problems I found.
>> >
>> > 1. The resulting file was not GEDCOM compliant
>>
>> Tim,
>>
>> All known Gramps and GEDCOM differences are listed here:
>>
>> http://www.gramps-project.org/wiki/index.php?title=Gramps_and_GEDCOM
>>
>> If there is one thing that Gramps attempts to do right is be
>> GEDCOM-compliant, even if that means ignoring some standard, but
>> non-compliant, parts. After all, there are probably many competing
>> extensions---how would we decide which is more important? If you can
>> provide details on what you believe is non-compliant, that is the only
>> way we can fix the issue. You can even upload a GEDCOM to the tracker
>> and mark it private so that we can test. Or email it to a developer
>> for private testing.
>>
>> > 2. All Multimedia records were thrown away (i.e. OBJE)
>>
>> As Benny mentioned, there are a couple of possible issues. We are also
>> working on adding functionality on this point.
>>
>> > 3. All user defined records were thrown away (i.e. _NNNN)
>>
>> That is non-standard GEDCOM, right?
>>
>> > 4. All embedded notes were converted to linked notes, which in itself is
>> > not a problem, but they reused existing note record ids resulting in
>> > duplicates, which no application could possibly use.
>>
>> Are you sure about that? If so, definitely a bug, but we'd need an
>> example to track down the problem.
>>
>> > 5. They wrapped all tag data at 80 characters using the CONT tag,
>> > unfortunately, GEDCOM does not allow many records to be wrapped like the
>> > CAUS and NAME tags, resulting in invalid record fields.
>>
>> As far as we know, we produce valid GEDCOM. Could it be that your
>> other program is in error?
>>
>> > 6. Social Security Number tags were thrown away.
>>
>> Not likely. More likely is that the ended up as an attribute of the
>> person. But again, this is non-standard GEDCOM, right?
>>
>> > The list goes on, but chances are if you tried to import this file into
>> > another genealogy program you would get errors and lose data.
>>
>> Every program handles GEDCOM differently, but we can't help what other
>> programs do. We can only be as conformant as possible to the GEDCOM
>> standard.
>>
>> > I
>> > reimported the file to Gramps, and as expected, due to duplicate note
>> > ids, the wrong notes were linked to individuals, and important data was
>> > missing. It did handle the invalid wrapping properly.
>>
>> We take each issue seriously, and we have a well-defined process for
>> dealing with issues: each problem should be reported here:
>>
>> http://www.gramps-project.org/bugs/main_page.php
>>
>> For more information on issues, please see:
>>
>> http://www.gramps-project.org/wiki/index.php?title=How_to_report_bugs
>>
>> -Doug
>>
>> > Posted by Tim Forsythe to Ancestors Now at January 2, 2012 6:32 AM
>
>

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

Tim Lyons
Administrator
In reply to this post by Nick Wallingford-2
Tim Forsythe wrote
5. They wrapped all tag data at 80 characters using the CONT tag,
unfortunately, GEDCOM does not allow many records to be wrapped like the
CAUS and NAME tags, resulting in invalid record fields.
My understanding of the GEDCOM standard is that any records can be wrapped with CONT/CONC tags, and I presume that Gramps takes this view too.

However, I accept that this may be a misreading of the GEDCOM standard, and anyway, trying to implement an interchange standard is not much use unless it allows interchange.

Hence, I have a simple question: which GEDCOM records _ARE_ allowed to be wrapped? I assume we all agree notes can be wrapped. Are n DSCR <PHYSICAL_DESCRIPTION> lines allowed to be wrapped? Are n PROP <POSSESSIONS> lines allowed to be wrapped? (Both these elements can be up to 248 characters long)

Since GEDCOM lines can't be longer than 255 (wide) characters, I resume that any lines can be wrapped if they would otherwise be longer than 255 characters, so the questions only apply to lines that are less than 255 characters.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

Tim Forsythe
This post has NOT been accepted by the mailing list yet.
Tim,

The GEDCOM grammar indicates that all values can be broken using the CONT/CONC tags.
The GEDCOM form only lists them for specific places.

This causes confusion in interpretation (obviously I am still occasionally tripped up), but the grammar should always trump the form, so the CONT/CONC should be allowed everywhere.  We can then assume the form only listed 'obvious' places that would use it.

I was confused because Gramps uses an 80 char length instead of 255, so wrapping strings at 80 chars though unusual does not seem to violate the GEDCOM specification.

Tim Forsythe


On Tue, Jan 3, 2012 at 10:44 AM, Tim Lyons [via GRAMPS] <[hidden email]> wrote:
Tim Forsythe wrote
5. They wrapped all tag data at 80 characters using the CONT tag,
unfortunately, GEDCOM does not allow many records to be wrapped like the
CAUS and NAME tags, resulting in invalid record fields.
My understanding of the GEDCOM standard is that any records can be wrapped with CONT/CONC tags, and I presume that Gramps takes this view too.

However, I accept that this may be a misreading of the GEDCOM standard, and anyway, trying to implement an interchange standard is not much use unless it allows interchange.

Hence, I have a simple question: which GEDCOM records _ARE_ allowed to be wrapped? I assume we all agree notes can be wrapped. Are n DSCR <PHYSICAL_DESCRIPTION> lines allowed to be wrapped? Are n PROP <POSSESSIONS> lines allowed to be wrapped? (Both these elements can be up to 248 characters long)

Since GEDCOM lines can't be longer than 255 (wide) characters, I resume that any lines can be wrapped if they would otherwise be longer than 255 characters, so the questions only apply to lines that are less than 255 characters.


If you reply to this email, your message will be added to the discussion below:
http://gramps.1791082.n4.nabble.com/Wrongly-posted-to-gramps-bugs-tp4254018p4257555.html
This email was sent by Tim Lyons (via Nabble)
To receive all replies by email, subscribe to this discussion

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly posted to gramps-bugs...

Julio Sánchez-2
In reply to this post by Benny Malengier

2012/1/3 Benny Malengier <[hidden email]>
Thanks for the reply Tim.
With this mail, the rest of the list can read it too.

Greetings,
Benny

2012/1/3 Tim Forsythe <[hidden email]>:
>
> #4
> 7800 embedded notes in my GEDCOM file were converted to linked notes
> starting with N0000.  However, my GEDCOM file already had linked notes for
> N1 thru N115, so the exported file has duplicates for those 115 note
> records, i.e. N0000, N0001, N0001, N0002, N0002, ... N0115, N0115, N0116,
> N0117 ... N7800.   I would think you could test this easy enough by
> importing a file with 1 linked note in the form of '0 @N1@' and see if you
> end up with two '0 @N0001@' records on export.

I personally hate linked notes in GEDCOM output except when necessary, but I wonder if some program (Gramps or other) mistakingly assumes that @N1@ and @N0001@ are the same xref.  They are not.  Expecting them to be a letter plus an integer and then assigning that integer any mystical significance is not supported by the specification (quoting from random sections in the 5.5 spec):

pointer:= [(0x40) + alphanum + pointer_string + (0x40) ]

where: (0x40)=@

pointer_char:= [non_at ]

pointer_string:=[null | pointer_char | pointer_string + pointer_char ]

and later:

xref_id:=
(See pointer, page 15)
The xref_id is formed by any arbitrary combination of characters from the pointer_char set. The first character must be an alpha or a digit. The xref_id is not retained in the receiving system, and it may therefore be formed from any convenient combination of identifiers from the sending system. No meaning is attributed by the receiver to any part of the xref_id, other than its unique association with the associated record. The use of the colon (:) character is also reserved.

Later, we are told that they can't start with #, either.  But that's it.

I.e. xrefs are opaque strings.  Any program that interprets @N1@ and @N0001@ as the same xref is IMHO broken.

Best regards,

Julio

--
Julio Sánchez Fernández, CISM, CISA, CRISC, CGEIT



------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Loading...