2013/5/28 Enno Borgsteede <ennoborg@gmail.com>

That's your SQL hat speaking. Time to put it back in the closet and think NoSQLy. ;-) If these data are normalized they'd just have to be joined every time you wanted to use them. Yes, it would save a little space, but only at the cost of more complex queries and slower response.
Ok, ok, forget SQL. When I wrote normalized I was thinking about the design where you put fields in the right tables. We have that in Gramps, even though Gramps is noSQL. Person names are in the person table, dates in the events, and so forth. I call that normalized, even though it's not in a pure relational way. That's OK.

Likewise, we put author and title in the source table, page/volume and date in the citation table, which is where I also paste the contents from a record that I find on FamilySearch or Wie Was Wie. So far, so good.

Now, with the evidence style prototype, which I just tried in trunk, it appears as if everything goes to the citation table now. In one way, I think that's very simple and straightforward, but it also looks like a diversion from the way we went from sources to citations in Gramps 3.4.

Just to be clear, there is no prototype in trunk. Only source data has been converted to attribute for other reasons. At the same time I added a lot of _possible_ types according to fields present in EE. Nothing more.

As to exchange, if GEDCOM is used, it will be like current Gramps by necessity, so pub info, page/vol, ... . We could generate those though on export if that is what we choose to do. We will not parse on import though, as that is not workable.

I don't plan on reading GedcomX, if there are good ideas there, it would be good if you summarize it in a clear and short manner. My idea on working in a team is that not every teammember must know as much as the all the others. If that where needed, one could work alone.