Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > There is no semantic difference between > > 0 FAM > 1 HUSB > 1 WIFE > 1 MARR > 2 DATE > > and > > <fam> > <husb> </husb> > <wife> </wife> > <marr> > <date> </date> > </marr> > </fam> > > or > > <tribe> > <head> </head> > <staff> </staff> > <union> > <jour> </jour> > </union> > </tribe> Not having looked at the XML-based proposals, I'm not familiar with what's being proposed, but if the preceding is a valid example, I don't see any significant benefit. As you say, there's not semantic difference and clutter is being added for no obvious reason.
On Wed, 18 Jul 2007 07:45:07 PST, mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote in soc.genealogy.computing: >Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: >> There is no semantic difference between >> >> 0 FAM >> 1 HUSB >> 1 WIFE >> 1 MARR >> 2 DATE >> >> and >> >> <fam> >> <husb> </husb> >> <wife> </wife> >> <marr> >> <date> </date> >> </marr> >> </fam> >> >> or >> >> <tribe> >> <head> </head> >> <staff> </staff> >> <union> >> <jour> </jour> >> </union> >> </tribe> > >Not having looked at the XML-based proposals, I'm not familiar >with what's being proposed, but if the preceding is a valid >example, I don't see any significant benefit. As you say, >there's not semantic difference and clutter is being added for >no obvious reason. While not exactly the same, XML and HTML are somewhat similar. You can look at any HTML page to get an idea about what XML looks like. Keep in mind the exact syntax is different. The gain is because there are more and more tools to read XML files and to handle this kind of data, event if it is not the same as you use in genealogy. For example, a family is a set of persons where 2 persons have a special role (dad and mom), and the other persons a more general role (kids). You can say a car is a of pieces, or an army regiment is a set of persons, etc. Then you can define database operations like putting someone in the right box by dragging that person, i.e. drag John to the dad's box or to the captain's box, or drag the name of the cathedral to the relevant box, etc. So, in theory, you could achieve many predefined operations with the same code and getting some universal genealogy software that will process the persons, but also the events, the places, the groups (army, state employees, churchmen, town elected, trades), the sources, etc. Then you get some kind of very powerful genealogy system. The drawback is if it is too easy, you will get 1000 standards because everybody will create his/her own universal genealogy package. Another drawback is the freedom you get will cut you from getting back to any lineage-oriented databases i.e. from almost any existing genealogy software. Denis
Denis Beauregard wrote: ... > The gain is because there are more and more tools to read XML > files and to handle this kind of data, event if it is not the > same as you use in genealogy. > > For example, a family is a set of persons where 2 persons have > a special role (dad and mom), and the other persons a more > general role (kids). You can say a car is a of pieces, or an > army regiment is a set of persons, etc. Then you can define > database operations like putting someone in the right box by > dragging that person, i.e. drag John to the dad's box or to the > captain's box, or drag the name of the cathedral to the relevant > box, etc. So, in theory, you could achieve many predefined > operations with the same code and getting some universal > genealogy software that will process the persons, but also the > events, the places, the groups (army, state employees, churchmen, > town elected, trades), the sources, etc. Then you get some kind > of very powerful genealogy system. > ... > > Denis > But that's not specific to XML? Peter
On Wed, 18 Jul 2007 18:19:54 +0100, Peter J Seymour <moz@pjsey.demon.co.uk> wrote in soc.genealogy.computing: >Denis Beauregard wrote: >... >> The gain is because there are more and more tools to read XML >> files and to handle this kind of data, event if it is not the >> same as you use in genealogy. >> >> For example, a family is a set of persons where 2 persons have >> a special role (dad and mom), and the other persons a more >> general role (kids). You can say a car is a of pieces, or an >> army regiment is a set of persons, etc. Then you can define >> database operations like putting someone in the right box by >> dragging that person, i.e. drag John to the dad's box or to the >> captain's box, or drag the name of the cathedral to the relevant >> box, etc. So, in theory, you could achieve many predefined >> operations with the same code and getting some universal >> genealogy software that will process the persons, but also the >> events, the places, the groups (army, state employees, churchmen, >> town elected, trades), the sources, etc. Then you get some kind >> of very powerful genealogy system. >> >... >> >> Denis >> >But that's not specific to XML? What is specific to XML is the development of tools to handle this kind of structures. GEDCOM can be developed by genealogists only. XML can be developed by any programmer, so more development is expected. Denis
Denis Beauregard wrote: > For example, a family is a set of persons where 2 persons have > a special role (dad and mom), and the other persons a more > general role (kids). You can say a car is a of pieces, or an This is a good description of MOST families, but one of the flaws of GEDCOM is that it institutionalizes the false notion that there is no other kind of family. Sure, they eventually put in ways to get around it, but those ways are klugey and not supported by many programs. However, because GEDCOM _is_ adequate for most families, it is "good enough" for all but the most fanatic of genealogists. Thus the K-Mart philosophy takes hold-- if 90% of people don't need what you want, you can't have it. -- Wes Groleau Alive and Well http://freepages.religions.rootsweb.com/~wgroleau/
Everett M. Greene wrote: > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > >>There is no semantic difference between >> >>0 FAM >>1 HUSB >>1 WIFE >>1 MARR >>2 DATE >> >>and >> >><fam> >> <husb> </husb> >> <wife> </wife> >> <marr> >> <date> </date> >> </marr> >></fam> >> >>or >> >><tribe> >> <head> </head> >> <staff> </staff> >> <union> >> <jour> </jour> >> </union> >></tribe> > > > Not having looked at the XML-based proposals, I'm not familiar > with what's being proposed, but if the preceding is a valid > example, I don't see any significant benefit. As you say, > there's not semantic difference and clutter is being added for > no obvious reason. simply said both xml and gedcomn are text files with diffeent forms of mark up language Hugh W -- a wonderful artist in Denmark http://www.ingerlisekristoffersen.dk/ Beta blogger http://snaps4.blogspot.com/ photographs and walks old blogger GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG
Everett M. Greene wrote: > Not having looked at the XML-based proposals, I'm not familiar > with what's being proposed, but if the preceding is a valid > example, I don't see any significant benefit. As you say, > there's not semantic difference and clutter is being added for > no obvious reason. That's why I said, it's like going from English to pig-Latin. Semantically there is no difference. Any flaws in the GEDCOM data model are in both versions. And there are flaws, though GEDCOM obviously is not completely useless. (And that's why no one seems to be in a big hurry to fix it.) I can think of two advantges of XML: 1. Open source and commercial XML parsers are everywhere. 2. If you know how to use XSL, you can write a presentation stylesheet. Your GEDCOM (XML) file plus the XSL is all that's necessary for a sufficiently modern browser to make a fairly nice web page. In other words, instead of writing code to transform GEDCOM into HTML, you write a high-level spec for that code, and the user's browser does all the rest of the work! -- Wes Groleau Promote multi-use trails in northeast Indiana! http://www.NorthwestAllenTrails.org/