On 12/30/2012 5:20 PM, Ron Savage wrote:
Hi Paul
On 31/12/12 08:19, Paul Johnson wrote:
On Sun, Dec 30, 2012 at 10:13:53AM +0100, Mikkel Eide Eriksen wrote:
On 30/12/2012, at 05.08, Ron Savage<r...@savage.net.au> wrote:
On 30/12/12 13:46, Philip Durbin wrote:
GEDCOMX seemed to arrive full of bluster, Java and XML, and gave the
impression that the only unsolved problems were things like deciding how
to store the XML and then just finishing the programming. That was
rather uninteresting to me.
Far more interesting was the data model, and despite the programming
going on, GEDCOMX didn't seem to have that nailed down. And as far as
it was exposed, it didn't really seem to build on any of the other work
that had taken place in this area over the last decade or so.
I'm impressed by the amount of work which has been done, and a bit
disconcerted where it ties in to Java. I do see the attempt to adopt
material from the Java world, and elsewhere, but the link to Java seems
a bit too tight for my liking.
Likewise adopting the Zip format, as its max size limitations become
more and more apparent, given their comment about (optionally) storing
everything in a single file (if I understood that, of course).
Overall though, I'm worried if they haven't over-specified things, in
classic Java style, which leaves me feeling there may have to be a
auxiliary spec answering the question: What are they really saying (at
each point)? This would collapse several layers of definitions, if needed.
I spent some hours reading through the specs and I come away with the
follow thoughts:
1. I like what they are trying to do
2. I think it is overly complex, but may be it needs to be
3. There are major holes or areas that things are under specified, for
example:
* addresses as mentioned
* place names as a single string that would require additional parsing
to make sense of
* events a lot of defined but a lot are not, like military induction for one
4. I didn't like the connection to Java either, I see no need for that
in the spec, if there is some point that they are trying to establish by
it, it would be better to just spell it out in details so people that do
not work with Java have direct guidance.
And probably other things. I think it would require a lot of UI stuff to
hide the complexity of this but that should not be a show stopper.
-Steve
