2013/5/22 Nick Hall <nick__hall@hotmail.com>
On 22/05/13 19:36, Benny Malengier wrote:
Well, keep in mind that I always have birth and death certificates in mind, not census. I'm ok with xml for defining the fields, but what to store based on this is better in a python module we can easily debug in my opinion. Over generalization is nice for programmers, but difficult for a project as Gramps to maintain. So I rather not describe in some xml what code should do, let's just write code.

This is what the census editor does at the moment.  It means that you would have to write a different "save" script for each certificate type, and users would only be able to define new sub-types.



Now you have input in column form, we could easily provide two possibilities: one the column entry, the other one line in the column in editor form on a notebook, with new tabs for every line in the column entry. Some certificates work best in one form, others in the other, but they are 1-1 mapping, so one xml to define them  (Note that for twins you have two birth cert at the same time, so birth cert needs option of more than one also).

Yes, you could generate a different input form based on the same xml definition.



Next is translation. Things like census.xml better have not

        <column>
            <_attribute>Relation</_attribute>
            <size>10</size>
        </column>

but instead a key, with a value added to the key which is translated. So, I now see,

                attr_text = _(attr[0].childNodes[0].data)
But it would be better to have a map
attr2en, so
              attr_text = _(attr2en[attr[0].childNodes[0].data])
which translates Relation to the English Relation. In this way, <_attribute>Relation</_attribute> could be <_attribute>Rel1</_attribute>
instead, and errors in column name and such don't change keys later on.
attr2en can be defined in the xml itself, or in python, not sure what is best. I we want users to be able to write extensions, the first I suppose.

The problem I have in the census addons is that we use Gramps attributes to store values.  We want the key to be human readable and not a code.  The human readable attribute is stored in the xml.

I understand, but a Dutch user does not want Occupation in his attributes, he wants the Dutch "Beroep" stored. For Occupation no problem probably as it is perhaps an existing type, but for other columns it might.

In python tradition, I don't propose to have actually rel1, but instead something readable, just that rel1 should work just as good. English is not something special, rel1 needs to be translated to a language, be it English or another. This mapping can be in the xml itself, I would just prefer it explicit, instead of implicit as now.


It is nice to be able to see all the attributes in the event reference editor.  At the top attributes tab you can see the values for the person (columns), in the shared event section attributes tab you can see the values for the event (headings).

At present, the census report reads these values.

Are you proposing that we don't copy attributes into the event and event reference objects from the certificate object?

No, I'm proposing to store it in the certificate object, and if user generates data from the certificate, to store it in the event/ event reference or other object too depending on what is fitting for the certificate. What is stored in the objects can be different from what is in the certificate though.
Eg, a person could write
Name: Nick Hal
if it appears like that in the census, but then connect this to person Nick Hall.
So a censusline would actually probably be: column, value, handle 
where handle is the object where data of that censusline is stored after generation. Perhaps even a bit more complex, as a line can lead to a person object, or an attribute of a person.

For census we have census event, so logical to store there values. For birth certificate, we normally only store source and birth event, but birth event is not when the certificate is actually written, so it makes no sense there to add what is stored in a birth certificate in the birth event.


A tooltip entry in the xml would be nice too.

The census xml uses the <longname> tag for tooltips in the editor and column headings in the report.  We could separate them and have a <tooltip> tag.


In my proposal, type would be census for a census event, subtype UK1901, ... .
The subtype can set different attributes, but the type defines how certificate data will be stored. I suppose some columns are required, like Name in census.

Yes, this will work.  In fact I have some experimental code that uses the same approach.  :)


All in all, I think it is doable, but a good GEP has to be written, and we must agree on it, as once implemented, we need to keep supporting it.

Is anyone actually thinking of doing this?

I'm itching, but I estimate more work than I have time for :-(

Nick.