Hi Paul On Sat, 2011-08-06 at 12:30 +0200, Paul Johnson wrote: > On Sat, Aug 06, 2011 at 10:20:30AM +1000, Ron Savage wrote: > > Hi Folks > > > > This is the first time I've seen a GEDCOM XML 6.0 doc, although I > > suppose many people are familiar with it. > > > > http://bettergedcom.wikispaces.com/message/view/Data+Models/32554704 > > > > Should we discuss it here, or join the other group? > > I'm not sure it's worth discussing it at all really. At least not > from the standpoint of using it to push forward newer work. However, > some of the following projects may be of more interest: > > http://www.ngsgenealogy.org/cs/GenTech_Projects > http://gdmxml.fugal.net/ > http://www.cosoft.org/genxml/ > http://www.sunflower.com/~billk/GEDC/
Thanx. I'm glad to collect such references. And the more I collect the more I am convinced piggy-backing on one or more of them is the way forward. > Over the years there have been many initiatives aimed at improving on > GEDCOM. As you can see none of them have really caught on. I believe > this is because no one with sufficient clout has sufficient incentive to > move away from GEDCOM. GEDCOM 5.5 is sufficient for the LDS church to > do what it wants to do. And it is sufficient for software application > vendors to create software that people will buy. A bit sad. And given the effort in GenXML (say) it seems pointless to start from scratch. > Even if anyone does create a good new format, they will still need to > support GEDCOM import and export, at least initially, so where is the > benefit? Yes, that type of compatibility is inescapable, since no matter what the new code does, those switching to it will be only ever some subset of all people in the field. > That's not to say that this can't or shouldn't happen. We can look at > document formats to see a case where formats can be improved (or, at > least, updated) and trying to save in an earlier format can result in a > warning that data may be lost. Yep. > It's probably worth noting too, that somewhat contradicting what I wrote > earlier, the LDS church has been active in this area recently: > > https://devnet.familysearch.org/docs/api-overview OK. But as it happens, I don't feel like registering with them just now... > And finally, just a general note. Many previous discussions have got > bogged down technicalities. Should we use XML? What date format? What > character encoding? These matters are trivialities in the scheme of > things. Once the actual genealogical model is clear the rest is just > programming. Of course, most of us are programmers ... I see this as the result of several factors: o Most researchers are not programmers. o Researchers who are programmers (or who have access to programmers) don't necessarily have the time. o Programmers who at least have the time are rarely database designers. My last shouldn't be taken to imply I think dbs are the best or only storage mechanism, but that I don't view storage for storage's sake. Rather, the storage has to serve the purpose of making data available, not just holding it, and I took a decision years ago that delivery via the web was where I'd focus my efforts. This means efficient access to whatever part of the data the user (viewer) wanted (hence my earlier comment re viewports), and hence my reluctance to embrace anything which requires parsing XML to service each access request. So, I confess, I still see dbs and their random access feature, as the best storage - at the moment. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
