gedcom-parse-devel Mailing List for The Gedcom parser library
Status: Beta
Brought to you by:
verthezp
Menu
▾
▴
gedcom-parse-devel — Discussions about development on gedcom-parse
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Peter V. <Pet...@ad...> - 2003-04-04 17:46:00
|
Hi Steve, > Thanks, Peter, > > I have a working version of gedcom-parse now that supports TYPE, > FONE and ROMN subfields in NAME, and also FONE & ROMN in PLAC. > I think I'll finish adding all of the 5.5.1 features, before I > send diffs. I'm adding these as optional features, and I added > an option to turn them on, so you can process "generic" 5.5.1 > compliant GEDCOMs. Seems to be a good idea. Until now, my philosophy was that when the file declares itself as GEDCOM 5.5, it should be 5.5 and not 5.5.1. But it looks like some programs just do that anyway, and it would be nice to support that, instead of converting them to user defined tags (with underscores prepended). > > One thing I noticed that I don't understand is a call to > gedcom_set_compat_options(0) in gom_parse_file(). I've commented > this out in my working version, since I want to use > getcom_set_compat_options() from, e.g. gedcom-sanitize, to enable > 5.5.1 compatibility. > Do you know why this is being called? Doesn't seem to make > sense to me. This is described in the documentation here: http://gedcom-parse.sourceforge.net/doc/usage.html#Compatibility_mode gedcom_set_compat_options() does not enable or disable compatibility mode, it's gedcom_set_compat_handling() that does that. gedcom_set_compat_options() just gives some control of what the compatibility mode is allowed to do. Currently there is only one option (COMPAT_ALLOW_OUT_OF_CONTEXT), which is useful if enabled, but can be fatal (with segfaults) to programs that are not prepared for it. Have a look at the documentation. Note that in the CVS sources, this is now enabled in the GOM, because I've reworked the context handling a bit. This is not in any released version yet. > > I would also like to join genes, though I'm focusing on > gedcom-parse at the moment. > > I did notice one problem with genes. When I have Chinese names, > which are formed like > 1 NAME /Surname/Givenname > rather than the western tradition of Givenname/Surname/, genes > seems to be losing the given name, or at least it is not > displayed. Probably the code to parse the name did not anticipate > that they might be reversed. > Please be sure the name order from the gedcom file is preserved > when displaying these names, otherwise Asian notes will be mangled. This is something that Geert will take care of (the split is now mostly that I work on the parser and Geert on genes...) Best regards, Peter. -- =================================================================== Peter Verthez Software engineer Email: mailto:Pet...@ad... WWW: http://users.skynet.be/Peter.Verthez PGP key: on homepage (see above) or http://www.keyserver.net =================================================================== Semper in faecibus sumus, sole profundum variat. |
|
From: Steve S. <Ste...@su...> - 2003-04-03 22:15:58
|
Thanks, Geert! -steve Geert Vantienen wrote: > Steve Swales wrote: > >> I would also like to join genes, though I'm focusing on gedcom-parse >> at the moment. > > > Hello Steve, > > I have added you to genes as a developer. > It will still take some time before I have time enough to continue > with the > development of genes. But I already put some changes in CVS and I planned > to update the handling (reading and writing) of dates in a better way, > before > doing a next release. > > Kind regards, > Geert > >> I did notice one problem with genes. When I have Chinese names,which >> are formed like >> 1 NAME /Surname/Givenname >> rather than the western tradition of Givenname/Surname/, genes seems >> to be losing the >> given name, or at least it is not displayed. Probably the code to >> parse the name did not anticipate that they might be reversed. >> Please be sure the name order from the gedcom file is preserved when >> displaying these names, otherwise Asian notes will be mangled. > > > I have to look at it... > -- Steve Swales Senior Manager, Platform Globalization Engineering X.Org Chairperson Sun Microsystems, Inc. 2515 North First Street, MS USJC07-201 San Jose, CA 95131 Direct 408 635-0623 Fax 408 635-0670 E-mail ste...@su... |
|
From: Geert V. <Gee...@sk...> - 2003-04-03 21:00:47
|
Steve Swales wrote: > I would also like to join genes, though I'm focusing on gedcom-parse > at the moment. Hello Steve, I have added you to genes as a developer. It will still take some time before I have time enough to continue with the development of genes. But I already put some changes in CVS and I planned to update the handling (reading and writing) of dates in a better way, before doing a next release. Kind regards, Geert > I did notice one problem with genes. When I have Chinese names,which > are formed like > 1 NAME /Surname/Givenname > rather than the western tradition of Givenname/Surname/, genes seems > to be losing the > given name, or at least it is not displayed. Probably the code to > parse the name did not anticipate that they might be reversed. > Please be sure the name order from the gedcom file is preserved when > displaying these names, otherwise Asian notes will be mangled. I have to look at it... -- ----------------------------------------------------------------------------- If you do not like Microsoft, do not pirate their products, use real software (Linux). ----------------------------------------------------------------------------- |
|
From: Steve S. <Ste...@su...> - 2003-04-03 17:29:18
|
Thanks, Peter,
I have a working version of gedcom-parse now that supports TYPE, FONE
and ROMN subfields in NAME, and also FONE & ROMN in PLAC.
I think I'll finish adding all of the 5.5.1 features, before I send
diffs. I'm adding these as optional features, and I added an option
to turn them on, so you can process "generic" 5.5.1 compliant GEDCOMs.
One thing I noticed that I don't understand is a call to
gedcom_set_compat_options(0) in gom_parse_file(). I've commented this
out in my working version, since I want to use
getcom_set_compat_options() from, e.g. gedcom-sanitize, to enable 5.5.1
compatibility.
Do you know why this is being called? Doesn't seem to make sense to me.
I would also like to join genes, though I'm focusing on gedcom-parse at
the moment.
I did notice one problem with genes. When I have Chinese names,which
are formed like
1 NAME /Surname/Givenname
rather than the western tradition of Givenname/Surname/, genes seems to
be losing the
given name, or at least it is not displayed. Probably the code to parse
the name did not anticipate that they might be reversed.
Please be sure the name order from the gedcom file is preserved when
displaying these names, otherwise Asian notes will be mangled.
-steve
Peter Verthez wrote:
> Hi Steve,
>
>> I would like to join the gedcom-parse developer team. I am
>> working on genealogy software which can support Chinese
>> names, and would like to help work on gedcom-parse and genes.
>>
>
> I've added you as a developer for gedcom-parse. I cannot add you
> as a developer to genes myself, because Geert Vantienen (firework)
> is the administrator, but I've put him on CC. I'm sure he will
> add you (neither of us know Chinese, so that is a welcome addition
> :-))
>
> My development has gone down a bit the last month; I was mainly
> cleaning up the documentation for gedcom-parse (put it in Doxygen).
> So if you want to tackle the bug you have submitted, be my guest.
>
> Geert and I know each other personally, so we did most of the
> discussions in private, but I propose we use the mailing list
> gedcom-parse-devel now for discussions.
>
> Cheers,
> Peter.
--
Steve Swales
Senior Manager, Platform Globalization Engineering
X.Org Chairperson
Sun Microsystems, Inc.
2515 North First Street, MS USJC07-201
San Jose, CA 95131
Direct 408 635-0623
Fax 408 635-0670
E-mail ste...@su...
|
|
From: Peter V. <Pet...@ad...> - 2003-04-03 16:31:14
|
Hi Steve, > I would like to join the gedcom-parse developer team. I am > working on genealogy software which can support Chinese > names, and would like to help work on gedcom-parse and genes. > I've added you as a developer for gedcom-parse. I cannot add you as a developer to genes myself, because Geert Vantienen (firework) is the administrator, but I've put him on CC. I'm sure he will add you (neither of us know Chinese, so that is a welcome addition :-)) My development has gone down a bit the last month; I was mainly cleaning up the documentation for gedcom-parse (put it in Doxygen). So if you want to tackle the bug you have submitted, be my guest. Geert and I know each other personally, so we did most of the discussions in private, but I propose we use the mailing list gedcom-parse-devel now for discussions. Cheers, Peter. -- =================================================================== Peter Verthez Software engineer Email: mailto:Pet...@ad... WWW: http://users.skynet.be/Peter.Verthez PGP key: on homepage (see above) or http://www.keyserver.net =================================================================== God, root, what is difference ? Pitr from User Friendly |
|
From: Peter V. <Pet...@ad...> - 2003-02-02 16:10:50
|
Hi all, I've made a new release of the Gedcom parser library. Since the interface should now be complete (barring bug fixes and requests), I've gone to beta and bumped up the release number closer towards 1.0.0. See the NEWS file for a description of the changes (and some backward incompatibilities). Compatibility with existing programs (notably PAF) should be much better now, although I guess there is still a lot of work in that area. A known restriction is that the library causes crashes if you compile with profiling enabled. I haven't really found the cause yet (it seems to be a corruption in the interface between C libraries, strange...). Best regards, Peter. -- =================================================================== Peter Verthez Software engineer Email: mailto:Pet...@ad... WWW: http://users.skynet.be/Peter.Verthez PGP key: on homepage (see above) or http://www.keyserver.net =================================================================== All the world's stage and most of us are desperately unrehearsed. Sean O'Casey |
|
From: Peter V. <Pet...@ad...> - 2003-01-03 17:20:07
|
just a test, please ignore -- =================================================================== Peter Verthez Software engineer Email: mailto:Pet...@ad... WWW: http://users.skynet.be/Peter.Verthez PGP key: on homepage (see above) or http://www.keyserver.net =================================================================== To be or not to be is true. Or maybe not. G. Boole |
|
From: Peter V. <Pet...@ad...> - 2002-09-14 13:06:31
|
Hi all,
This week I've released version 0.17 of the Gedcom parser.
The main new feature is the addition of a C object model. If you
would compare the callback parser to the SAX interface of XML, then
the C object model is comparable to the DOM interface of XML. In
many ways, the C object model is easier to use, but it is a little
less flexible.
See the NEWS file in the distribution for some interface changes
(and backward incompabilities) that are caused by this.
My further objectives are (not necessarily in order):
- support for modifying data (actually, this is already possible
in the C object model, but it requires too much internal
knowledge)
- support for writing GEDCOM files, and maybe GEDML files
- C++ object model (perl also ?)
- more compatibility with other genealogy programs.
Now, my call for help... It is in fact two-fold:
- I'd like to see examples of GEDCOM files made by other programs
(e.g. PAF, FTM, ...), to be able to enhance the compatibility
of the parser with the non-standard GEDCOM syntax enhancements
of other programs.
- If you have a GEDCOM file with embedded multimedia objects in
it (i.e. the BLOB tag) I'd like to see it. I want to be able
to decode multimedia blobs correctly, but I have the impression
that this is one of the least standard-abiding features in
GEDCOM, mainly because the standard is a little ambiguous in
its description about it...
Any comments on the Gedcom parser are always welcome. Also have
a look at Genes (genes.sourceforge.net) which uses this parser
natively.
Best regards,
Peter.
--
===================================================================
Peter Verthez Software engineer
Email: mailto:Pet...@ad...
WWW: http://users.skynet.be/Peter.Verthez
PGP key: on homepage (see above) or http://www.keyserver.net
===================================================================
Semper in faecibus sumus, sole profundum variat.
|
|
From: Peter V. <Pet...@sk...> - 2002-01-20 15:37:20
|
Hi all,
I've released version 0.14 of the GEDCOM parser library. Here are
the release notes:
release 0.14 (20 January 2002):
- This is mainly a bugfixing release, no extra features have been
added.
- Some example code is available on how to convert from UTF-8 to
the locale system, and how to check the library version via
configure.in (see the documentation for details).
Best regards,
Peter.
--
===================================================================
Peter Verthez Software engineer
Email at work: mailto:Pet...@al...
at home: mailto:Pet...@sk...
WWW: http://gallery.uunet.be/Peter.Verthez
===================================================================
50 billion flies can't be wrong: eat shit !
|
|
From: Peter V. <Pet...@ad...> - 2002-01-05 16:06:41
|
Hi all,
A new release is available. These are the release notes (changes
with respect to 0.12):
- Cross-references are now parsed and checked. For this, an extra type
is
added to the types possible in a Gedcom_val: an xref pointer. This
means
that GEDCOM_XREF_PTR has to be used now in some places instead of
GEDCOM_STRING.
A quick change is to replace
GEDCOM_STRING(val)
by
GEDCOM_XREF_PTR(val)->string
where applicable. But you can also store an object in the 'object'
member
of the struct returned by GEDCOM_XREF_PTR (see documentation).
- Other interface changes in the callbacks:
- parsed tag value (integer) is passed next to the string value
- the start record callbacks now also contain a Gedcom_val (the NOTE
can
have a value)
- Further, various bugfixes have been made.
Now is the time to do some bug squatting...
Cheers,
Peter.
--
===================================================================
Peter Verthez Software engineer
Email at work: mailto:Pet...@al...
at home: mailto:Pet...@ad...
WWW: http://gallery.uunet.be/Peter.Verthez
===================================================================
while (!asleep()) sheep++;
|
|
From: Peter V. <Pet...@ad...> - 2002-01-03 10:56:25
|
Hi Geert,
The problem is corrected in CVS.
I've also added two extra arguments to the start record callbacks,
because a record can also have a value (e.g. a NOTE record). Docs
already updated...
Cheers,
Peter.
--
===================================================================
Peter Verthez Software engineer
Email at work: mailto:Pet...@al...
at home: mailto:Pet...@ad...
WWW: http://gallery.uunet.be/Peter.Verthez
===================================================================
Veni, vidi, velcro (I came, I saw, I stuck around).
|
|
From: Peter V. <Pet...@ad...> - 2002-01-03 09:56:24
|
Geert Vantienen wrote: > > Hello Peter, > > I have a question about notes: > If you run the testgedcom with the allged.ged > then you will find the note tags in the testgedcom.out file > If you search for these NOTE tags, the first ones are ok, > but then you get lines like: > == 2 NOTE 3 (ctxt is 10000) Yep, seems like a bug. I'll correct it... Cheers, Peter. > > coming from: > > 1 LANG English > 1 CHAN > 2 DATE 19 JUN 2000 > 3 TIME 12:34:56.789 > 2 NOTE A note > 3 CONT Note continued here. The word TE > 3 CONC ST should not be broken! > 1 _MYOWNTAG This is a non-standard tag. Not recommended but allowed > > Where is the text "A note" gone ? > > Kind regards, > Geert > > _______________________________________________ > Gedcom-parse-devel mailing list > Ged...@li... > https://lists.sourceforge.net/lists/listinfo/gedcom-parse-devel -- =================================================================== Peter Verthez Software engineer Email at work: mailto:Pet...@al... at home: mailto:Pet...@ad... WWW: http://gallery.uunet.be/Peter.Verthez =================================================================== Veni, vidi, velcro (I came, I saw, I stuck around). |
|
From: Geert V. <Gee...@pa...> - 2002-01-02 22:01:08
|
Hello Peter, I have a question about notes: If you run the testgedcom with the allged.ged then you will find the note tags in the testgedcom.out file If you search for these NOTE tags, the first ones are ok, but then you get lines like: == 2 NOTE 3 (ctxt is 10000) coming from: 1 LANG English 1 CHAN 2 DATE 19 JUN 2000 3 TIME 12:34:56.789 2 NOTE A note 3 CONT Note continued here. The word TE 3 CONC ST should not be broken! 1 _MYOWNTAG This is a non-standard tag. Not recommended but allowed Where is the text "A note" gone ? Kind regards, Geert |
|
From: Peter V. <Pet...@ad...> - 2002-01-02 20:17:55
|
Hi Geert, I've added an argument to the callbacks: the parsed tag value. I've updated the docs also (usage.html). The #define's are in gedcom-tags.h, but you won't find it in CVS: it's autogenerated when you do 'make'. Cheers, Peter. PS. Don't do too much on xref's yet. I'm now going to make an interface for it (=E0 la GEDCOM_DATE, but then GEDCOM_XREF_PTR) and implement checking. Geert Vantienen wrote: >=20 > >=3D=3D=3D=3D=3D Original Message From Peter Verthez <Peter.Verthez@adv= alvas.be> =3D=3D=3D=3D=3D > >Geert Vantienen wrote: > >> > >> Hello Peter, > >> > >> In the callbacks you now pass the tag as a char*, > >> is it possible to pass them as enum value as they > >> are defined in the gedcom.h file ? > > > >No problem, but then you'll need both, because if I just pass > >e.g. ELT_SUB_INDIV_GEN, then you won't know which tag it really > >was. > > > >Or did you mean passing them as TAG_BIRT, TAG_DEAT, ... ? Those > >are not defined in gedcom.h, but in the header generated by > >YACC. But maybe that would even be better. >=20 > I was talking about TAG_DEAT, ... they were not defined in gedcom.h ? > oops, I thought they were ... >=20 > I'll see whether > >I can move these to gedcom.h. But then also, you'll need the > >original char* value to, at least for the user-defined tags. >=20 > That is not a problem ... >=20 > Thanks, > Geert >=20 > _______________________________________________ > Gedcom-parse-devel mailing list > Ged...@li... > https://lists.sourceforge.net/lists/listinfo/gedcom-parse-devel --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Peter Verthez Software engineer Email at work: mailto:Pet...@al... at home: mailto:Pet...@ad... WWW: http://gallery.uunet.be/Peter.Verthez =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Customer: "What do you mean, other tape? When it said second volume, I just hit enter again." |
|
From: Geert V. <Gee...@ad...> - 2002-01-02 11:39:42
|
>===== Original Message From Peter Verthez <Pet...@ad...> ===== >Geert Vantienen wrote: >> >> Hello Peter, >> >> In the callbacks you now pass the tag as a char*, >> is it possible to pass them as enum value as they >> are defined in the gedcom.h file ? > >No problem, but then you'll need both, because if I just pass >e.g. ELT_SUB_INDIV_GEN, then you won't know which tag it really >was. > >Or did you mean passing them as TAG_BIRT, TAG_DEAT, ... ? Those >are not defined in gedcom.h, but in the header generated by >YACC. But maybe that would even be better. I was talking about TAG_DEAT, ... they were not defined in gedcom.h ? oops, I thought they were ... I'll see whether >I can move these to gedcom.h. But then also, you'll need the >original char* value to, at least for the user-defined tags. That is not a problem ... Thanks, Geert |
|
From: Peter V. <Pet...@ad...> - 2002-01-02 09:34:32
|
Geert Vantienen wrote: > > Hello Peter, > > In the callbacks you now pass the tag as a char*, > is it possible to pass them as enum value as they > are defined in the gedcom.h file ? No problem, but then you'll need both, because if I just pass e.g. ELT_SUB_INDIV_GEN, then you won't know which tag it really was. Or did you mean passing them as TAG_BIRT, TAG_DEAT, ... ? Those are not defined in gedcom.h, but in the header generated by YACC. But maybe that would even be better. I'll see whether I can move these to gedcom.h. But then also, you'll need the original char* value to, at least for the user-defined tags. Best regards, Peter. > This would simplify the callback of : > ELT_SUB_INDIV_GEN because this one is used > for almost all events. > > Thanks, > Geert > > _______________________________________________ > Gedcom-parse-devel mailing list > Ged...@li... > https://lists.sourceforge.net/lists/listinfo/gedcom-parse-devel -- =================================================================== Peter Verthez Software engineer Email at work: mailto:Pet...@al... at home: mailto:Pet...@ad... WWW: http://gallery.uunet.be/Peter.Verthez =================================================================== You know you've been hacking LISP too long, (if (> (count #\( sentence) *a-lot*)) |
|
From: Peter V. <Pet...@ad...> - 2002-01-02 00:55:16
|
Happy New Year to all !
Just before the festivities of New Year's Eve yesterday, I released
a new version of gedcom-parse (0.12).
Release notes are as follows (I can't seem to get them uploaded
to the file release page):
================================================================
release 0.12 (31 December 2001):
- The calling of callbacks is now completed.
- Some initial documentation is available.
- The parsed value that is returned in callbacks can now be:
- a null value
- a string
- a date (struct date_value)
See the documentation for more info. Parsing and checking of
cross-references will be added next.
================================================================
Best regards,
Peter.
--
===================================================================
Peter Verthez Software engineer
Email at work: mailto:Pet...@al...
at home: mailto:Pet...@ad...
WWW: http://gallery.uunet.be/Peter.Verthez
===================================================================
I'm not a complete idiot, some parts are missing.
|
|
From: Geert V. <Gee...@pa...> - 2002-01-01 21:55:02
|
Hello Peter, In the callbacks you now pass the tag as a char*, is it possible to pass them as enum value as they are defined in the gedcom.h file ? This would simplify the callback of : ELT_SUB_INDIV_GEN because this one is used for almost all events. Thanks, Geert |
|
From: prapp <pr...@er...> - 2001-12-30 18:47:34
|
>PS: The "1 TIME" bug in the header was reported & fixed in LifeLines >only recently (it should, as Peter says, be "2 TIME"). In fact, the >headers were missing some other mandatory lines until recently. LifeLines, if recent enough version, will fill in all the mandatory header lines (I think), but if you have any non-ascii data, you need to inform it of the correct HDR_CHAR line, via an entry in your .linesrc (or lines.cfg) of the form: HDR_CHAR=1 CHAR UTF-8 (By default it will say ASCII there.) - Perry |
|
From: prapp <pr...@er...> - 2001-12-30 18:40:28
|
>Lifelines doesn't seem to be very strict on the Gedcom spec. >It will take a lot of work to have compatibility, but eventually >it will have to be done... I'd go much further, and say LifeLines doesn't care much about the spec, frankly. You can maintain GEDCOM data that is completely correct by the lineage-linked standard (when you enter new records, just don't leave blank values in places that they aren't legal in lineage-linked GEDCOM), but you can also maintain event-linked GEDCOM if you wish, or almost any homebrew type of GEDCOM. The LifeLines UI only really understands lineage-linked GEDCOM, but it doesn't much help you maintain perfectly correct lineage-linked GEDCOM, so the onus is on the user to know the rules. I imagine that the best course of action is what Geert is doing -- exporting it & running it thru a parser, and finding out, however painfully, what the rules are :) - Perry PS: The "1 TIME" bug in the header was reported & fixed in LifeLines only recently (it should, as Peter says, be "2 TIME"). In fact, the headers were missing some other mandatory lines until recently. PPS: A nifty little LifeLines program that outputs a database in GEDCOM, but fills in placeholders for blank values that are not legally blank, would be nice... |
|
From: Peter V. <Pet...@ad...> - 2001-12-30 18:16:24
|
Hi Geert, Lifelines doesn't seem to be very strict on the Gedcom spec. It will take a lot of work to have compatibility, but eventually it will have to be done... Geert Vantienen wrote: > > I have also empty source lines (I guess this was my own mistake when > adding a new > person with lifelines: > ERROR: Error on line 18: Missing value > > 0 @F1@ FAM > 1 HUSB @I1@ > 1 WIFE @I2@ > 1 MARR > 2 DATE 21 Aug 1865 > 2 PLAC Kermt > 2 SOUR > 1 CHIL @I78@ > ... Indeed, the SOUR tag needs a value (either a pointer or a simple text giving the source description). > > Something simular for: > ERROR: Error on line 219: Missing value > 0 @S5@ SOUR > 1 REFN > 1 TITL doodsbrief > 1 AUTH > 0 @F10@ FAM > ... Similar for the REFN and AUTH tags... > > I also have errors like: > ERROR: Error on line 932: The tag 'CITY' is not a valid tag within 'RESI' > ERROR: Error on line 933: The tag 'POST' is not a valid tag within 'RESI' > > 0 @I44@ INDI > 1 NAME X/XX/ > 1 SEX M > 1 RESI > 2 ADDR Zelebaan 000 > 2 CITY Lokeren > 2 POST 9160 > 1 NOTE xxxxxxxxxxx > 1 FAMC @F11@ > 0 @I45@ INDI > > I thought that in a RESI block you could have a ADDR block in which you > can have > POST and CITY lines ... > http://homepages.rootsweb.com/~pmcbride/gedcom/55gcch2.htm#ADDRESS_STRUCTURE Correct, but CITY and POST have to be one level down, not at the same level as ADDR... Lots of work to have compatibility !! Cheers, Peter. -- =================================================================== Peter Verthez Software engineer Email at work: mailto:Pet...@al... at home: mailto:Pet...@ad... WWW: http://gallery.uunet.be/Peter.Verthez =================================================================== I have great faith in fools: Self confidence my friends call it. Edgar Allan Poe |
|
From: Peter V. <Pet...@ad...> - 2001-12-30 18:06:27
|
Hi Geert,
As it says: it's invalid syntax according to the Gedcom spec
(the TIME tag should be on level 2). Compatibility with
non-standard syntaxes is not in yet...
Cheers,
Peter.
Geert Vantienen wrote:
>
> Hello Peter,
>
> I have downloaded the latest sources from the cvs tree, and I compile
> it,
> then I tried the testgedcom on my own gedcom file
> produced by lifelines.
>
> [gvtienen@gandalf t]$ ../testgedcom -2 ~/cvs/geert.ged >tmp.output
> ERROR: Error on line 5: The tag 'TIME' is not a valid tag within 'HEAD'
> ERROR: Error on line 1: parse error
>
> 0 HEAD
> 1 SOUR LIFELINES 3.0.6
> 1 DEST ANY
> 1 DATE 26 AUG 2001
> 1 TIME 10:31
> 0 @F1@ FAM
> 1 HUSB @I1@
> 1 WIFE @I2@
> ...
--
===================================================================
Peter Verthez Software engineer
Email at work: mailto:Pet...@al...
at home: mailto:Pet...@ad...
WWW: http://gallery.uunet.be/Peter.Verthez
===================================================================
I have great faith in fools: Self confidence my friends call it.
Edgar Allan Poe
|
|
From: prapp <pr...@er...> - 2001-12-30 18:05:52
|
At 02:53 PM 2001-12-30 +0100, Geert Vantienen wrote: >0 @I44@ INDI >1 NAME X/XX/ >1 SEX M >1 RESI >2 ADDR Zelebaan 000 >2 CITY Lokeren >2 POST 9160 >1 NOTE xxxxxxxxxxx >1 FAMC @F11@ >0 @I45@ INDI > >I thought that in a RESI block you could have a ADDR block in which you >can have >POST and CITY lines ... >http://homepages.rootsweb.com/~pmcbride/gedcom/55gcch2.htm#ADDRESS_STRUCTURE FWIW, your CITY appears to be at level 2, so it is not within the ADDR, but within the RESI. |
|
From: Geert V. <Gee...@pa...> - 2001-12-30 13:59:42
|
Geert Vantienen wrote: > Hello Peter, > > I have downloaded the latest sources from the cvs tree, and I compile > it, > then I tried the testgedcom on my own gedcom file > produced by lifelines. > > [gvtienen@gandalf t]$ ../testgedcom -2 ~/cvs/geert.ged >tmp.output > ERROR: Error on line 5: The tag 'TIME' is not a valid tag within 'HEAD' > ERROR: Error on line 1: parse error > > 0 HEAD > 1 SOUR LIFELINES 3.0.6 > 1 DEST ANY > 1 DATE 26 AUG 2001 > 1 TIME 10:31 > 0 @F1@ FAM > 1 HUSB @I1@ > 1 WIFE @I2@ > ... > > Kind regards, > > Geert Hello, After updating (several times) the gedcom file with an editor: ERROR: Error on line 5: The tag 'SUBM' is mandatory within 'HEAD', but missing ERROR: Error on line 6: The tag 'GEDC' is mandatory within 'HEAD', but missing ERROR: Error on line 9: The tag 'CHAR' is mandatory within 'HEAD', but missing I have also empty source lines (I guess this was my own mistake when adding a new person with lifelines: ERROR: Error on line 18: Missing value 0 @F1@ FAM 1 HUSB @I1@ 1 WIFE @I2@ 1 MARR 2 DATE 21 Aug 1865 2 PLAC Kermt 2 SOUR 1 CHIL @I78@ ... Something simular for: ERROR: Error on line 219: Missing value 0 @S5@ SOUR 1 REFN 1 TITL doodsbrief 1 AUTH 0 @F10@ FAM ... I also have errors like: ERROR: Error on line 932: The tag 'CITY' is not a valid tag within 'RESI' ERROR: Error on line 933: The tag 'POST' is not a valid tag within 'RESI' 0 @I44@ INDI 1 NAME X/XX/ 1 SEX M 1 RESI 2 ADDR Zelebaan 000 2 CITY Lokeren 2 POST 9160 1 NOTE xxxxxxxxxxx 1 FAMC @F11@ 0 @I45@ INDI I thought that in a RESI block you could have a ADDR block in which you can have POST and CITY lines ... http://homepages.rootsweb.com/~pmcbride/gedcom/55gcch2.htm#ADDRESS_STRUCTURE Kind regards, Geert |
|
From: Geert V. <Gee...@pa...> - 2001-12-30 13:20:17
|
Hello Peter, I have downloaded the latest sources from the cvs tree, and I compile it, then I tried the testgedcom on my own gedcom file produced by lifelines. [gvtienen@gandalf t]$ ../testgedcom -2 ~/cvs/geert.ged >tmp.output ERROR: Error on line 5: The tag 'TIME' is not a valid tag within 'HEAD' ERROR: Error on line 1: parse error 0 HEAD 1 SOUR LIFELINES 3.0.6 1 DEST ANY 1 DATE 26 AUG 2001 1 TIME 10:31 0 @F1@ FAM 1 HUSB @I1@ 1 WIFE @I2@ ... Kind regards, Geert |
