In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert > Melson) wrote in soc.genealogy.computing: > >>As I understand it, though, XML permits you to add/delete >>entities locally while still preserving the "universal" >>entities defined elsewhere. If that's true, then you >>should be able to add a "hippie marriage" entity in your >>local DTD that would satisfy your requirements. > > From a structural point of view, where is the difference > with GEDCOM ? > > > Denis > I'm not sure I can answer that question. Anything I think I know about XML comes from the O'Reilly "XML in a Nutshell" and is rusty as hell. (Hmmm, now I think of it, though, both V5.X and V6 are GEDCOM - the realization is different from one to the other, though.) I think the major difference between 5 and 6, however, is not in the representation but in the entities included and how they're defined. I haven't really looked at the BNF definitions of the GED language, so I can't really tell you specifically how the two versions differ. The advantage of XML, though, as I understand it, is that there can be a centrally defined stylesheet which can be imported into the local environment and modified locally without affecting the base stylesheet. You could even, if I remember correctly, have multiple stylesheets - the base, a vendor version, an o/s specific version, one for your company and your personal version. In terms of the GED standard, you might have the central "standard" maintained at and by the LDS, a FTM version maintained by the vendor, and a local version you maintain yourself to fix problems you see in the other two. If there's anybody here who understands this, I'd love to see/hear what you have to say about the GED V.6 beta standard and what it will mean for us mere hackers. Bob Melson -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- "People unfit for freedom---who cannot do much with it---are hungry for power." ---Eric Hoffer

Robert Melson wrote: > In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: > >>On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert >>Melson) wrote in soc.genealogy.computing: >> ... > > The advantage of XML, though, as I understand it, is that there can > be a centrally defined stylesheet which can be imported into the > local environment and modified locally without affecting the base > stylesheet. You could even, if I remember correctly, have multiple > stylesheets - the base, a vendor version, an o/s specific version, > one for your company and your personal version. In terms of the > GED standard, you might have the central "standard" maintained at > and by the LDS, a FTM version maintained by the vendor, and a > local version you maintain yourself to fix problems you see in > the other two. > ... > > Bob Melson > There might be something in this is if there were several versions on a straight line dependency, but once you have a tree of dependecies (as you inevitably would) you're stuck. Also if you encountered a data field that isn't defined in the definitions you have because it's defined elsewhere, you also also stuck. The problem with local versions is that they probably won't be known in all the places they need to be known. Basically XML doesnt help. Regards Peter

Robert Melson wrote: > In article <iuvq93105be5ochbsi73dh7u0rforplirg@4ax.com>, > Denis Beauregard <denis.b-at-francogene.com@fr.invalid> writes: >> On Wed, 18 Jul 2007 02:07:01 GMT, melsonr@aragorn.rgmhome.net (Robert >> Melson) wrote in soc.genealogy.computing: >> >>>As I understand it, though, XML permits you to add/delete >>>entities locally while still preserving the "universal" >>>entities defined elsewhere. If that's true, then you >>>should be able to add a "hippie marriage" entity in your >>>local DTD that would satisfy your requirements. >> >> From a structural point of view, where is the difference >> with GEDCOM ? >> >> >> Denis >> > > I'm not sure I can answer that question. Anything I think I > know about XML comes from the O'Reilly "XML in a Nutshell" > and is rusty as hell. (Hmmm, now I think of it, though, both > V5.X and V6 are GEDCOM - the realization is different from one > to the other, though.) > > I think the major difference between 5 and 6, however, is not in > the representation but in the entities included and how they're > defined. I haven't really looked at the BNF definitions of > the GED language, so I can't really tell you specifically how > the two versions differ. > > The advantage of XML, though, as I understand it, is that there can > be a centrally defined stylesheet which can be imported into the I think you mean DTD or schema. That's what specifies the data format. DTD is pretty well moribund. Schemas are more powerfull. Stylesheets are what you'd use to specify the transformations between, say a standard version and a vendor-specific version. > local environment and modified locally without affecting the base > stylesheet. You could even, if I remember correctly, have multiple > stylesheets - the base, a vendor version, an o/s specific version, > one for your company and your personal version. In terms of the Apart from the terminology this is correct. I did a number of projects for a client who provided personalised print services where their clients would specify the XML they were sending to be processed. I used stylesheets to transform the various client schemas into into a common in-house schema so that I could handle them all with a common application code-base. > GED standard, you might have the central "standard" maintained at > and by the LDS, a FTM version maintained by the vendor, and a > local version you maintain yourself to fix problems you see in > the other two. > > If there's anybody here who understands this, I'd love to see/hear > what you have to say about the GED V.6 beta standard and what it > will mean for us mere hackers. > > Bob Melson > I took a quick look at the proposed new standard a few weeks ago. As I recall it had actually dropped some components of the original. This would make it far less able to deal with some of the issues raised in a long-running thread in s.g.methods earlier this year. XML has several advantages. Firstly its notions of well-formedness and validaty ensure that a corrupt file or the product of a program generating off-spec XML is easily picked up. Secondly the use of XSLT allows transformation into XML of a different schema, HTML or text formats, possibly even existing non-XML Gedcom. Thirdly there are well-established libraries in all major languages for parsing XML so there's no reason why any application developer should have to roll their own and get it wrong. I doubt it's a passing fad. It's the language I wish I'd had available donkey's years ago for exchanging data. But that's what it is - a language for data exchange. And the issues being raised here are essentially about the data model behind Gedcom. In order to produce a worthwhile replacement one would really have to produce a new data model which is accepted as better than that in use. As far as I can see one weakness of existing data models is that there is a direct link between entities. In another post in this thread I gave an example of how handling of uncertainties could be a property of an improved system but as far as I can see this would be impossible to implement with direct links - one would need additional link entities/classes/tables. The development process would, then be: 1. Data model. 2. Data exchange specification (XML or otherwise). 3. Implementation. -- 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