On 22/05/13 22:51, Benny Malengier wrote:



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.

I introduced translations into the xml very soon after I made the census addons public.  They work the same way as the tips and holidays files.

Tags are marked for translation by prefixing them with a leading underscore.  The make script then uses intltool to extract the translatable strings.  I'm don't understand why you want to use a different approach for certificates.




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.

So for a census the storage is the same, except we also store the certificate.  This makes things easy.


Eg, a person could write
Name: Nick Hal
if it appears like that in the census, but then connect this to person Nick Hall.

Yes, this is what the census editor does.  The name is just stored as another attribute.  The name column is actually populated with the name of the person by default, but it can be change to the actual text.


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.


I think we should consider a Persona object, with a name, type/role, handle and key/value pairs.  A Certificate would contain an ordered list of Personas and headings as key/value pairs.  The Persona would contain a person handle when linked to a person.

The data stored after generation can be located through back links from the citation object.

It will be nice to have the ability to create a persona without having to link it to 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.

I have had requests to create extra objects from census entries, such as Occupation and Residence events.  I prefer to review the Occupation attributes in the censuses and create an Occupation attribute.  Residence events are not really useful for censuses, but will be for birth, marriage and death certificates.




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 :-(

Let me know if you need any help.

Nick.



Nick.