Ian Goddard wrote: > The problem is that the unknown tag is part of the structure and has to > be recognised by the parser. In XML we would have an element such as > <OptionalData> with an attribute such as "type". Both of these would be > part of the structure and _any_ program using the schema as import would > recognise them. The value of the attribute and the element would GEDCOM structure also allows for non-standard tags. It also has a few poorly defined tags that have to be clarified by a free-form TYPE or NOTE. It even added the PEDI and TYPE tags to put free-form modifiers on the formerly narrowly defined NAME and CHIL tags. And of course, there are many well-defined tags that some programs do not support. Whether an item is a GEDCOM tag or an XML element, what does a program do that has no place for it in its internal data structures? Unless you forbid it, it will do what the LDS's own PAF program does: stick it in a NOTE. (or discard it completely). Either response prevents the data from being properly used after that by a program that _does_ support it. Recoding the GEDCOM 5.5 data model into the 6.0 XML structure does not solve any problem with the data model. Nor does offering a new structure solve the problem of the spec not being followed. The solution to GEDCOM's problems involves not only a better data model, but also sufficient demand that software vendors feel the need to adopt it. Several of the former may exist, but the latter does not. -- Wes Groleau If you put garbage in a computer nothing comes out but garbage. But this garbage, having passed through a very expensive machine, is somehow ennobled and none dare criticize it.

Wes Groleau wrote: > Ian Goddard wrote: > >> The problem is that the unknown tag is part of the structure and has >> to be recognised by the parser. In XML we would have an element such >> as <OptionalData> with an attribute such as "type". Both of these >> would be part of the structure and _any_ program using the schema as >> import would recognise them. The value of the attribute and the >> element would > > > GEDCOM structure also allows for non-standard tags. > It also has a few poorly defined tags that have to be clarified > by a free-form TYPE or NOTE. It even added the PEDI and TYPE tags > to put free-form modifiers on the formerly narrowly defined NAME > and CHIL tags. And of course, there are many well-defined tags > that some programs do not support. Whether an item is a GEDCOM tag > or an XML element, what does a program do that has no place for it > in its internal data structures? Unless you forbid it, it will > do what the LDS's own PAF program does: stick it in a NOTE. > (or discard it completely). > > Either response prevents the data from being properly used after that > by a program that _does_ support it. > > Recoding the GEDCOM 5.5 data model into the 6.0 XML structure does > not solve any problem with the data model. Nor does offering a new > structure solve the problem of the spec not being followed. > > The solution to GEDCOM's problems involves not only a better data model, > but also sufficient demand that software vendors feel the need to > adopt it. Several of the former may exist, but the latter does not. > Precisely. To rehash my "eye color: Harvard" vs "Education: Grey" canard, if the data aren't equal/standard, then the exchange cannot be standardized. Which pretty much boils down to, if everyone used MY program-of-choice then data would transfer much more smoothly. Or, phrased differently: the only way for BigWally in St. George UT to receive 12-oz wine glasses from 8 different shippers is for 8 different shippers to SHIP 12-oz wine glasses. If the shipper ships 11-oz wine glasses, the means of shipping (FedEx, USPS, UPS, DHL, RailwayExpress, or Greyhound Bus) won't make 'em 12-ozs when they get to UT. IMO Cheryl