lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] organization of XML actuarial tables


From: Václav Slavík
Subject: [lmi] organization of XML actuarial tables
Date: Tue, 24 Apr 2012 17:35:17 +0200

Hi,

there's one thing we didn't discuss about the new actuarial tables format: how 
should the tables be organized into files?

Currently, there are just a few files (qx_cso.dat, qx_ins.dat, ...) with lots 
of tables in each of them; the tables are referenced by both filenames and 
table numbers in .database files. In the public data files, table numbers are 
globally unique, two different .dat files don't define the same table; I assume 
this is always the case. Also, multi-dimensional tables are represented as a 
series of simple tables in the SOA data files, plus an index in our .database 
file (DB_CurrCoiTable being a typical example; this is something we want to get 
rid of, replacing it with proper multi-dimensional tables).

How should we organize XML files for the tables? Should I preserve this 
bundling of multiple tables into a single file? From an outsider's point of 
view, having one XML file per one table makes most sense — with multi-dimension 
tables such DB_CurrCoiTable put into single file and with the files named 
descriptively, rather than by a number. But I'm not a user of LMI — would doing 
something else make more sense here?

Assuming we want to use one file per table approach, there's also the issue of 
getting reasonable names and converting multiple SOA tables into a single 
multi-dimensional one. I don't think this can be automated easily, can it?

Would it be reasonable to do the conversion in two phases like this:

(1) Convert SOA tables to simple XML files, without multi-dimensional tables 
and using SOA table numbers, e.g. "35.table" or "qx_ins.35.table" (if the .dat 
file matters and multiple sources for the same table number may be used on the 
same machine). Remove binary SOA loader code. Nothing would change for the 
users, the UI would remain the same, only the data files would be replaced.

(2) Clean up the data files later: remove unneeded tables (?), merge 
multi-dimensional ones, change references to tables into .table file references 
and get rid of table numbers.

? Or would it be less burden to do everything — including step (2) which 
involves updates to user data files — at once?

Thanks,
Vaclav


reply via email to

[Prev in Thread] Current Thread [Next in Thread]