JD <jd4x4@ wrote: > Wes Groleau <groleau+news@freeshell.org> wrote: > > >>Again, how is XML more flexible than GEDCOM? The flexibility, if any, >>has to be built into the semantics--the DTD and what is allowed to >>link to what. I may complain about areas where GEDCOM is a bit rigid, >>but overall, it's MORE flexible than many software implementations. >> >> >>Again, if you can't force them to comply with the GEDCOM 5.5 spec, you >>can't force them to comply with the GEDCOM 6 DTD or any other DTD, >>much less the semantic parts that a DTD cannot express. >> > > Again, XML-compliant means that the software would accept the file as > input. By doing that it SHOULD at least accept the information in the file Again, if you can't force GEDstand. compliance, you can't force XML compliance. How is not-compliant with X better than non-compliant with Y? Cheryl

"singhals" <singhals@erols.com> wrote in message news:baCdnRzfnefM9uvanZ2dnUVZ_vfinZ2d@rcn.net... > JD <jd4x4@ wrote: > >> Wes Groleau <groleau+news@freeshell.org> wrote: >> >> >>>Again, how is XML more flexible than GEDCOM? The flexibility, if any, >>>has to be built into the semantics--the DTD and what is allowed to >>>link to what. I may complain about areas where GEDCOM is a bit rigid, >>>but overall, it's MORE flexible than many software implementations. >>> >>> >>>Again, if you can't force them to comply with the GEDCOM 5.5 spec, you >>>can't force them to comply with the GEDCOM 6 DTD or any other DTD, >>>much less the semantic parts that a DTD cannot express. >>> >> >> Again, XML-compliant means that the software would accept the file as >> input. By doing that it SHOULD at least accept the information in the >> file > > Again, if you can't force GEDstand. compliance, you can't force XML > compliance. > > How is not-compliant with X better than non-compliant with Y? > > Cheryl Exactly. This thread has drifted into the realms of discussing how to build a replacement mechanism for a facility that is not used correctly in the first place. GEDCOM 5.5 is sufficiently rich to support 95% of data transfer needs. Currently, most programs appear to use 30%-80% of this richness appropriately. Changing the transport mechanism isn't going to change the content richness. Currently the more compliant programs are those that use GEDCOM as their base data model, and then extend for their own purposes. Family Tree Builder (My Heritage), phpGEDView, and Family Historian (Calico Pie) are examples of such programs. When and if GEDCOM 5.5 is ever used correctly and completely, and its shortcomings for certain situations are encountered, then is a reasonable time to discuss the need to extend or replace. Extension could easily be achieved by agreed additional standards using custom tags, or by extending the meaning of existing tags. For example some programs use "1 MARR N" to indicate "not married", even though "N" is not a valid value for MARR under the existing standard. While leaders such as Family Tree Maker believe (according to the help file) that there is no facility in GEDCOM to support image exports, it would seem that we remain a long way from the point where the genealogy program creators are likely to use the basic capabilities of the current GEDCOM standard to its full extent. Changing the transport mechanism won't make a jot of difference to this situation - it would still be transporting sub-optimal data. Nigel www.tcgr.bufton.org

Nigel Bufton wrote: > Exactly. This thread has drifted into the realms of discussing how to build > a replacement mechanism for a facility that is not used correctly in the > first place. Actually the title was GEDCOM as a *database* format. That's quickly dealt with. It lacks the index mechanisms & ACID (http://en.wikipedia.org/wiki/ACID) properties of a database format. It wasn't designed as such. What the thread has inevitably drifted into is a combination of GEDCOM's original purpose - a transfer format - and, all to often entangled with that, its underlying data model. > > GEDCOM 5.5 is sufficiently rich to support 95% of data transfer needs. GEDCOM 5.5 is sufficiently rich to support 100% of the specific purpose for which it was designed. Maybe it also supports 95% of the extended purposes of those who can't see much further than what it does. > Currently, most programs appear to use 30%-80% of this richness The 80% limit, of course, comes from the fact that only LDS and its members are interested in the full 100% of its design objectives. > appropriately. Changing the transport mechanism isn't going to change the > content richness. Agreed. That's why LDS have lost interest in changing it. But changing the the scope of what one wants to transport requires a change of the mechanism. > > When and if GEDCOM 5.5 is ever used correctly and completely, and its > shortcomings for certain situations are encountered, then is a reasonable When vision is bounded by the limitations then the shortcomings won't be perceived. > time to discuss the need to extend or replace. Extension could easily be > achieved by agreed additional standards using custom tags, or by extending > the meaning of existing tags. For example some programs use "1 MARR N" to > indicate "not married", even though "N" is not a valid value for MARR under > the existing standard. Really? In the 2000's you want to use the mechanisms of the 1980's? > > While leaders such as Family Tree Maker believe (according to the help file) > that there is no facility in GEDCOM to support image exports, it would seem > that we remain a long way from the point where the genealogy program > creators are likely to use the basic capabilities of the current GEDCOM > standard to its full extent. > > Changing the transport mechanism won't make a jot of difference to this > situation - it would still be transporting sub-optimal data. Yup. That's the problem -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk