Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: <snip> > BUT: with regards to genealogy, one has the problem of either some > organization defining a "doctype" for use (having a "doctype" file > defining the construct of a valid XML file allows for validation of XML > files -- without using a custom validator; the validator read the > defining doctype file and uses IT to validate the construct of the XML > file), or one leaves it freely defined. > > But... more... if one is going to use a validating XML parser, and a > validation doctype supplied by some organization, one has the same > problem as GEDCOM... It is quite likely that the doctype definition will > not support all features of the most complex programs (typically those > of the event-based systems: the late Ultimate Family Tree and the living > The Master Genealogist) or will specify stuff not supported by the > simpler programs (Family Tree Maker; from the GEDCOMs I've seen, > practically any data item that is not a pure BMDB or relationship > becomes a generic "fact" or "note"). > > Unvalidated XML would allow each program to define the structures > that are best matches for its data... but will not be usable by other Well, it's hard to remedy complex to simple data scenarios, but I don't think it's impossible. At a minimum if a schema is agreed to that is a "lowest common denominator", then evolution happens, and the defacto common denominator gets extended naturally. As for "proprietary" granularity, it's somewhat transparant by virtue of a schema with known rules, and at least a minimum schema standard that requires a software name & version. > programs... How is a program that expects: > > <date>mm/dd/yyyy</date> > > going to handle a file generated by a program that produces: > > <date> > <year>yyyy</year> > <month>mm</month> > <day>dd</dd> > </date> > Simply by "remapping" back & forth because the expected formats are defined in each schema. We can even add an attribute that indicates the calendar type without mucking things up. >> standard (ie Microsoft), rather than >> a proper standard for all such as >> GEDCOM. >> >> So should not we avoid a proprietary >> standard? >> Yes, but more importantly I think we need to look at the actual data, and not build "trees" or other judgements into the DATA, other than in the form of a heirarchy (which can be changed without loss of data integrity if we think about it analytically, imo). >> >> >> Cheers, >> >> Tom [Tom Perrett] <tomp@st.net.au> >> >>

JD <jd4x4@ wrote: > Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > > <snip> > >> BUT: with regards to genealogy, one has the problem of either some >>organization defining a "doctype" for use (having a "doctype" file >>defining the construct of a valid XML file allows for validation of XML >>files -- without using a custom validator; the validator read the >>defining doctype file and uses IT to validate the construct of the XML >>file), or one leaves it freely defined. >> >> But... more... if one is going to use a validating XML parser, and > > a > >>validation doctype supplied by some organization, one has the same >>problem as GEDCOM... It is quite likely that the doctype definition > > will > >>not support all features of the most complex programs (typically those >>of the event-based systems: the late Ultimate Family Tree and the > > living > >>The Master Genealogist) or will specify stuff not supported by the >>simpler programs (Family Tree Maker; from the GEDCOMs I've seen, >>practically any data item that is not a pure BMDB or relationship >>becomes a generic "fact" or "note"). >> >> Unvalidated XML would allow each program to define the structures >>that are best matches for its data... but will not be usable by other > > > Well, it's hard to remedy complex to simple data scenarios, but I don't > think it's impossible. At a minimum if a schema is agreed to that is a > "lowest common denominator", then evolution happens, and the defacto > common denominator gets extended naturally. As for "proprietary" > granularity, it's somewhat transparant by virtue of a schema with known > rules, and at least a minimum schema standard that requires a software > name & version. > > >>programs... How is a program that expects: >> >><date>mm/dd/yyyy</date> >> >>going to handle a file generated by a program that produces: >> >><date> >> <year>yyyy</year> >> <month>mm</month> >> <day>dd</dd> >></date> >> > Simply by "remapping" back & forth because the expected formats are > defined in each schema. We can even add an attribute that indicates the > calendar type without mucking things up. Don't forget 12 Thermidor XII when you're indicating calendar types; and don't miss the Hebrew and Hindu calendars which are lunar, or the occasional 13th month in the Hindu calendar or the difference between light 2nd and dark 2nd of the month and what's going to happen to the 2nd 14th of the month? Cheryl