RootsWeb.com Mailing Lists
Total: 1/1
    1. Re: Beyond GEDCOM
    2. Ian Goddard
    3. Everett M. Greene wrote: > Wes Groleau <groleau+news@freeshell.org> writes: >> 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! > > Those are valid points for those who are interested in generating > Web-oriented presentations. But what portion of people dealing > with genealogy are interested in doing that? Are you saying that we should be bound by the limited requirements of the least ambitious? Let's look at some of the possibilities if we move genealogy software into the 21st century: First there's what's known in the trade as re-purposing of data (no, I don't particularly like the word): Use of a stylesheet to convert an XML export to HTML is referred to above. Use of a stylesheet to convert an XML export to SVG ("SVG is a language for describing two-dimensional graphics and graphical applications in XML." - W3C).  Your data converted to a rescalable graphics format which can then be massaged by SVG-aware graphics packages, converted to PDF, JPEG or whatever. Use of a stylesheet to convert an XML export to Formatting Objects (FO).  FO is an XML schema to describe page formatting.  FO can then be converted to PDF, postscript, RTF, Word, OpenOffice etc. Secondly there's data re-use. There would be the necessity of exchanging data with legacy applications using Gedcom 5.5 or earlier.  Conversion of an XML export to non-XML is easy; just use a stylesheet.  Conversion the other way is less less easy as we would need parsers for the non-XML format. Then, if anyone were to develop packages for related fields, such as local history, there quite a number of people would find value in moving data both ways. Anyone starting from scratch with such an application would be thinking of XML as an export/import mechanism. With our hypothetical genealogical XML problem it would be quite easy - just write a stylesheet. Finally if big archives were to make data available in machine-readable form this would be XML (for instance A2A seems to be XML internally converted to HTML for output; converting this back to XML is somewhat like extracting an egg from an omelet so I've written to them to ask if raw XML could be provided). Again, import of such data into any other XML-enabled package would be easy - you've guessed it, just write a stylesheet. -- Ian Goddard Hotmail is for the benefit of spammers. The email address that I actually read is igoddard and that's at nildram dot co dot uk

    07/20/2007 12:39:44