Hallo,
f�r mich sind Entscheidungen gefallen und zugleich formuliere
ich in hoffentlich allen verst�ndlicher Form das Ziel das
am Ende aller Bem�hungen um und mit GEDCOM erreicht werden muss.
Beispiel aus der Zeit der "guten alten W�hrung", der DM:
Hallo,
Wenn wir ein- und denselben Datenbestand der Reihe nach �ber
...
dann MUSS gew�hrleistet sein, dass *nach* diesem Duchlauf
im *ersten* Programm alles wieder so dargestellt/abgebildet wird,
wie es ursp�nglich im ERST-Export dieses verlassen hat.
*lach
Das liest sich wie Fl�sterpost! 
Ich hoffe, ich habe mich zwar laienhaft aber verst�ndlich ausgedr�ckt.
Ja, ich verstehe das Problem. Wenn jedes Programm kompatibel ist,
dann klappt das auch. Bis auf die Felder, die nicht im Standard
enthalten sind. Aber um die geht es ja auch im ersten Schritt noch
gar nicht.
Das Programm, das an diesem "Circus" erfolgreich besteht, das
kann das Zertifikat "Programm�bergreifend im GEDCOM-Transfer
gepr�ft!" erhalten.
Das kann nicht nur das Zertifikat erhalten, das wird den sogar erhalten!
Sch�nen Gru�
Michael (Suhr)
Hallo Klaus,
das von Dir vorgeschlagene / erarbeitete Ziel
Unser Ziel um die Kompatibilität der Programme bezüglich GEDCOM:
----------------------------------------------------------------
Wenn wir ein- und denselben Datenbestand der Reihe nach über
alle Genealogie-Programme exportieren, importiern, exportieren,
importieren, exportieren, usw.....,dann MUSS gewährleistet sein, dass *nach* diesem Duchlauf
im *ersten* Programm alles wieder so dargestellt/abgebildet wird,
wie es urspünglich im ERST-Export dieses verlassen hat.Ich hoffe, ich habe mich zwar laienhaft aber verständlich ausgedrückt.
Das Programm, das an diesem "Circus" erfolgreich besteht, das kann
das Zertifikat "Programmübergreifend im GEDCOM-Transfer geprüft!"
erhalten.
ist für mich klar und verständlich.
Viele Grüße
Anton (Seitz)
Klaus Vahlbruch wrote:
dann MUSS gewährleistet sein, dass *nach* diesem Duchlauf
im *ersten* Programm alles wieder so dargestellt/abgebildet wird,
wie es urspünglich im ERST-Export dieses verlassen hat.
Kannst Du schon vergessen. Das ist nicht gewährleistet und kann nicht gewährleistet werden.
Um bei Beispielen zu bleiben, nimm einen Setzkasten, wie ihn die alten Buchdrucker hatten. Da gab es für jeden Buchstaben ein Fach. Nun werfe ich die die Buchstaben einer Druckseite zum einsortieren vor. Alles kein Problem. Bis zu dem Moment, wo plötzlich kyrillische Buchstaben auftauchen, für die Du kein Fach hast.
Was jetzt?
So ist es auch mit den verschiedenen Möglichkeiten von Genealogieprogrammen.
Das Programm, das an diesem "Circus" erfolgreich besteht, das kann
das Zertifikat "Programmübergreifend im GEDCOM-Transfer geprüft!"
erhalten.
Wenn Du das "Zertifikat" etwas abstufen würdest, könnte Dein Ansatzt funktionieren.
Stufe 1:
Grundlgende Daten werden übernommen und exportiert (Name; Datum, Ort und Bemerkung zu Geburt, Taufe, Ehe, Tod und Bestattung)
Stufe 2:
Zusätzliche Daten werden übernommen und exportiert (Adoption, Konfirmation, standesamtliche und kirchliche Ehedaten, individuelle Ereignisse)
Stufe 3:
Zu den vorgenannten Daten auch noch Quellen- und Herkunftsangaben
Das war jetzt ein Beispiel, das ich willkürlich festgelegt habe und das keinen Anspruch auf Sinnhaftigkeit erhebt. Hier ist sicher Diskusionsbedarf und ggf. auch mehr Stufen denkbar. Wo werden Bilder und andere Multimediadaten eingeordnet?
Für den Anwender wäre das sicher ein Kriterium, für den Hersteller völlig uninteressant. Was hat der Hersteller davon, das er sich soviel Mühe mit dem Export macht? Für ihn reicht es, wenn er in der Beschreibung stehen hat "Datenaustausch per Gedcom möglich". Der Anwender merkt die Einschrenkung erst, wenn der Hersteller sein Geld hat.
Hör Dich mal um, die meisten Anwender haben ein Programm gekauft, ohne sich vorher informiert zu haben. Selbst wenn, merken sie erst Später, dass sie ihren Bedarf falsch eingeschätzt haben.
MfG, Metti.
Hallo,
Kannst Du schon vergessen. Das ist nicht gew�hrleistet und kann
nicht gew�hrleistet werden.
Doch, es geht! Man merkt sich einfach die Felder, die sein eigenes
Programm nicht verarbeiten kann und gibt die beim Export unver�ndert
wieder aus.
Wenn Du das "Zertifikat" etwas abstufen w�rdest, k�nnte Dein Ansatzt
funktionieren.
Eine sehr sch�ne Idee, wie ich finde! �ber die Unterschiede der einzelnen
Stufen kann man ja noch reden, aber generell ist es ein gangbarer Weg! 
F�r den Anwender w�re das sicher ein Kriterium, f�r den Hersteller
v�llig uninteressant. Was hat der Hersteller davon, das er sich soviel
M�he mit dem Export macht?
Ich kann all meinen Kunden sagen, dass ihre Daten nicht verloren
gehen, selbst wenn sie mit einem anderen Programm arbeiten m�chten.
Einzige Bedingung - das andere Programm muss auch GedCom
importieren k�nnen. Und das ist eher ein Manko, als denn der Export.
Selbst wenn, merken sie erst Sp�ter, dass sie ihren Bedarf
falsch eingesch�tzt haben.
Das ist ganz normal, sp�ter ist man immer kl�ger.
Sch�nen Gru�
Michael (Suhr)
Liebe Programmierfreunde und Anwenderfreunde,
sagt mal : wie blau�ugig seid Ihr eigentlich?
Glaubt Ihr wirklich, dass sich alle professionellen und Hobby-Programmierer
auf so einen "Mist" einlassen?
Das w�rde doch bedeuten, dass nur ein oder zwei h�chstens drei Programme
(und zwar vermutlich professionelle) noch gekauft werden, weil sie
vermutlich das "Certifikat" bekommen haben.
Denn : sind wir doch mal ehrlich -
Die �brigen Progr�mmchen k�nnen doch gar nicht so schnell folgen mit der
Anpassung an den Standard.
Die Jungs, die diese "kleinen" Progr�mmchen programmieren, haben doch
hauptberuflich was besseres zu tun, als sich gleich immer hinzusetzen und zu
"updaten".
Im �brigen m��ten sie schon etwas Au�ergew�hnliches bringen, um aus dem
"Einerlei" der �brigen Programme hevorzustechen.
Und dann m��te doch der Preis auch noch stimmen !
Dass das, was ich eben so provokant von mir gegeben habe, nicht so ganz von
der Hand zu weisen ist, zeigt sich doch immer wieder auf allen Gebieten der
Wirtschaft.
Wenn n�mlich nicht von irgendwo "oben" ein Standard verordnet wird, macht
doch ohnehin jeder das, was er meint, dass es am besten ist.
Irgendwo sagt doch ein jeder : Das und das wird doch wenig oder gar nicht
ben�tigt und - - es �berlastet mein Programm nur und macht es langsamer.
Und - - wer von den Anwendern soll sich denn all die Funktionen merken?
Also lasse ich es erstmal weg.
Statt zu sagen :
Ich biete das als extra feature bzw. Modul an. Wer es dann ben�tigt oder
haben m�chte, kann es einbinden oder zukaufen usw.
Einige professionelle Programme / Anwendungen machen das zum Teil auch
so - - aber einfach noch zu wenige.
Michael Suhr wrote:
Kannst Du schon vergessen. Das ist nicht gewährleistet und kann
nicht gewährleistet werden.Doch, es geht! Man merkt sich einfach die Felder, die sein eigenes
Programm nicht verarbeiten kann und gibt die beim Export unverändert
wieder aus.
Stimmt.
Allerdings auch hier nur bedingt. Mein Programm kennt keine Familien. Die werden nur für Gedcom erzeugt. Informationen, die in den FAM-Records vorhanden sind und nicht bearbeitet werden können, kann ich keiner Familie zuordnen, weil es keine gibt.
Im übrigen werden das die wenigsten Programme machen. Der Hersteller hat daran kein Interesse.
MfG, Metti.
Eine Frage,
welchen Grund gibt es Daten von Programm A nach Programm B, dann nach
Programm C und dann wieder nach A zu transferieren.
Ich kann mir eigentlich nur zwei F�lle vorstellen:
A.) ich habe in Programm "B" eine Ausgabe, z.B. eine Ahnentafel, die mir
besser gef�llt. Dann �bertrage ich meine Daten nach Programm "B" und mache
meinen Ausdruck. Die paar (Grund)Daten, die ich in der Tafel brauch, sind
wohl kein Problem.
B.) Ich bin mit Programm A nicht mehr zufrieden und m�chte zu Programm C
weiterarbeiten.
Dann ist nat�rlich wichtig, das alle Daten �bernommen werden. Das sollte
auch kein Problem sein, es sei denn Programm "C" hat Felder, die ich bei
Programm "A" belegt habe, nicht. Das ist aber nicht ein Problem des
Programms, sondern der falschen Programmwahl.
Wenn ich mit einen Kleinbus komme und steige um auf einen Porsche, bleiben
einige Personen (Daten) zur�ck.
Wenn ich mir den Porsche (Programm B) nur f�r eine Spritztour (Ahnentafel)
ausleihe, sitzt meine Familie (Daten) immer noch im Kleinbus (Programm A),
wenn ich wiederkomme.
Mit freundlichen Gr��en
Gisbert (Berwe)
Hallo Metti,
> dann MUSS gewährleistet sein, dass *nach* diesem Duchlauf
> im *ersten*
> Programm alles wieder so dargestellt/abgebildet wird, wie es
> urspünglich im ERST-Export dieses verlassen hat.
Kannst Du schon vergessen. Das ist nicht gewährleistet und
kann nicht gewährleistet werden.
Natürlich kann man das gewährleisten - man muss es nur wollen und
entsprechend programmtechnisch realisieren.
Wenn beim Import ein "user defined Tag" auftaucht, dann muss dieser
ebenfalls als user-definierter Tag in der eigenen Datenbank angelegt werden
- und zwar in der gleichen Struktur wie in der zu importierenden Datei.
Dadurch werden alle Daten importiert und können beim Export wieder
ausgegeben werden. Inwieweit diese Daten in der Programmoberfläche (User
Interface) angezeigt und bearbeitet werden können, obliegt der Phantasie und
der Kreativität des Programmerstellers.
Viel problematischer sind die nonkonformen Verwendungen von Standard-Tags.
Tags sind nämlich immer nur in ihrer definierten Struktur zu verwenden. Dies
wird aber von vielen Genealogieprogrammen nicht beachtet. Hier muss die
Validierung ansetzen. Eine Zertifizierung muss daher meiner Meinung nach
folgende Kriterien abdecken:
- Abdeckungsgrad der möglichen Standard-Tags
- Verwendung der Standard-Tags in der korrekten Struktur, in korrekter Länge
und im korrekten Vorkommen (z.B. SEX einmal, NAME mehrfach)
- Unterstützung User-defined Tags
- Import und Export von unbekannten User-definded Tags
Gruß Peter
Peter Schulz wrote:
Wenn beim Import ein "user defined Tag" auftaucht, dann muss dieser
ebenfalls als user-definierter Tag in der eigenen Datenbank angelegt werden
- und zwar in der gleichen Struktur wie in der zu importierenden Datei.
Man kann nicht berücksichtigte Gedcomzeilen sicher irgendwo zwischenspeichern. Keine Frage. Das das nicht immer geht, hatte ich schon an anderer Stelle erklärt.
Inwieweit diese Daten in der Programmoberfläche (User
Interface) angezeigt und bearbeitet werden können, obliegt der Phantasie und
der Kreativität des Programmerstellers.
Da das Interessse daran im Regelfal nicht sonderlich hoch ist und selbst bei den Anwendern selten Bedarf ist (siehe Mail von Gisbert) wird es halt nicht gemacht. Anderes hat sicher höhere Priorität. So zumindest bei mir.
- Verwendung der Standard-Tags in der korrekten Struktur, in korrekter Länge
Das geht doch schon bei den meisten Programmen bei CHAR in die Hose.
Noch heute, wo alle aktuellen Betiebssysteme und wohl auch Programmiersprachen den Umgang mit Unicode unterstützen, werden hier teilweise sogar verbotene Parameter genutzt.
Wer bitteschön sollte diese Validierung durchführen?
Ich sehe es wie Gisbert, es ist eigentlich kein Bedarf vorhanden.
MfG, Metti.
Warum nur finde ich in der ganzen langen Mail nicht einen einzigen Punkt, den ich f�r richtig und nachvollziehbar erkenne?
Mit freundlichen Gr��en
Jan Escholt
sanddorn schrieb:
Jan Escholt wrote:
Warum nur finde ich in der ganzen langen Mail nicht einen einzigen Punkt, den ich für richtig und nachvollziehbar erkenne?
Möglicherweise bist Du kein Programmierer. Ich finde folgende Aussage nachvollziehbar:
"Mögen die Programmierer in dieser Liste nun sagen : der ist nur ein
Traumtänzer - laßt uns in die "Programmierer-Liste" wechseln Dort sind
wir wenigstens unter uns."
MfG, Metti.
Hallo Gisbert,
A.) ich habe in Programm "B" eine Ausgabe, z.B. eine
Ahnentafel, die mir besser gefällt.
B.) Ich bin mit Programm A nicht mehr zufrieden und möchte zu
Programm C weiterarbeiten.
Du hast "C" vergessen.
Es soll Ahnenforscher geben, die Ihre Forschungsergebnisse mit anderen
Gleichgesinnten austauschen.
Gruß Peter
S e h r, nachvollziehbar, Metti
lange in dieser Liste nichts Nachvollziehbareres gelesen...
Uli
P.S.: Nicht nachvollziehbar, sagte der Gerichtsvollzieher, als er beim Exmillion�r nichts zum vollziehen fand.
Stefan Mettenbrink schrieb:
Ich finde folgende Aussage nachvollziehbar:
- la�t uns in die "Programmierer-Liste" wechseln 
Dort sind
Hallo Peter,
v�llig richtig.
Dann kann C entweder alle Datenfelder �bernehmen, oder nicht.
Der Anwender von C hat von Daten, die im Feld YXZ stehen nichts, wenn sein
Programm das Feld YXZ nicht hat.
Das ist aber ein Problem von Programm C oder von Gedcom. Entweder der
Anwender will nicht mehr, oder er hat das falsche Programm.
Und das ich dann die Daten wiederhaben m�chte, sie in B einlese um sie dann
wider nach A zu holen ist wohl nicht so wahrscheinlich oder sinnvoll. Wenn
der Bedarf bestehen w�rde, sollte man besser eine Datensicherung machen.;-))
Mit freundlichen Gr��en
Gisbert (Berwe)
Berichtigung!!!!!!!!!!!
Es sollte nat�rlich hei�en:
Das ist aber ein Problem von Programm C, n i c h t von Gedcom. Entweder
der
Mit freundlichen Gr��en
Gisbert (Berwe)
Ach so!!
Gisbert Berwe schrieb: