Dennis Lee Bieber <wlfraed@[EMAIL PROTECTED]
> 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 sup****t 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 sup****ted by the
> simpler programs (Family Tree Maker; from the GEDCOMs I've seen,
> practically any data item that is not a pure BMDB or relation****p
> 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 im****tantly 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@[EMAIL PROTECTED]
>
>>
>>
|
