T.M. Sommers wrote: > Ian Goddard wrote: > >> T.M. Sommers wrote: >> >>> >>> I fail to see any technological advantages of XML over GEDCOM. Their >>> syntax is different, but their semantics are essentially the same: >>> both are lists of trees. >> >> >> The advantage of XML is the range of tools it provides. Given an XMLT >> engine such as Saxon you could transform your XML output into HMLT by >> writing a suitable stylesheet. Or into FO for a pretty-printer >> report. Or into an SVG file for a diagram. > > > Perhaps I should have been more explicit and said that I see no > advantages of XML over GEDCOM for the uses to which GEDCOM is put, > namely passing data back and forth between genealogical programs. You > seem to want to use XML as some sort of reporting language for your own > database. I suppose it would work for that, but why bother? If it's > your own program, you have direct access to the data, and can directly > create any kind of report you want, without the hassle of first > converting everything to XML first.. > >>> The availability of parsing tools for XML is not a real advantage. >>> You still have to write the callbacks, and that is where most of the >>> work is. A GEDCOM line is trivial to parse: it is either LEVEL TAG >>> DATA or LEVEL XREF TAG. >> >> >> That's for a SAX parser. > > > DOM, too. > >> I've used the Woods SAX parser in Delphi. The handler and call-backs >> are small compared to the volume of code which is simply reused. > > > No smaller than the comparable code to handle GEDCOM would be. > >>> GEDCOM allows users to define their own tags, and I don't know if XML >>> validating parsers can handle that. >> >> >> The main advantage of a validating parser is to prevent just that! In >> any thread about GEDCOM one usually finds complaints about limited >> inter-operability resulting from one package's not understanding >> anther's tags. > > > The main complaint, I think, is that programs do not implement all of > standard GEDCOM. There is no reason to believe that that would change > if GEDCOM were replaced by XML. > > And it is a bit ironic to use the *Extensible* Markup Language to > prevent genealogical programs from extending their data-transfer language. > >> One way to handle optional stuff like that in XML would be to use >> attributes, e.g. >> >> <OptionalData type="CauseOfDeath">Drowning</OptionalData> > > > Ugh. This is better than > > 2 CAUS Drowning > > how? this grinds on a gedcom is a text document an xml document is also text but with mark ups using css or other templates you can edit in more ways csv . . publication for human eyes is to paper or screen with or without attached or imbedded imsges or media any family tree program is a text editor it is possible to upload a gedcom to a database like Custodianm 3 for searches uploading a gedcom to http://worldconnect.rootsweb.com/ backs it up off site as a freebie and privatises it with the 1930 US Federsl census as the model cut off point point it also allows other ways of viewing and searching the data sharing is also to ancestry.com and its little sisters I also took an anentafel generated in http://worldconnect.rootsweb.com/ saved it and edited it in a wysywyg html editor and uploaded it elsewhere so it sits well in google googling my mothers maiden name http://www.google.com/search?num=100&hl=en&newwindow=1&q=%22alison+mary%22+lapham&btnG=Search enjoy and have a happy Christmas and a great New Year Hugh W -- For genealogy and help with family and local history in Bristol and district http://groups.yahoo.com/group/Brycgstow/ http://snaps4.blogspot.com/ photographs and walks GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG