[lmi] actuarial tables format (was Re: Terse list of valuable projects)

[Václav Slavík]

Hi,

On 12 Mar 2012, at 18:09, Greg Chicares wrote:
> Today, we're using only those two axes. Going forward, we want to add
> other axes; additional axes are limited to those already used in
> 'dbindex.hpp'.
...
> Many of these tables are shared among different "products". Some are quite
> large, so we'd want to avoid duplicating identical tables. Thus, in the
> "TgCOI" example above, 39, 37, etc. are pointers to tables; instead, we'd
> want a single pointer to a single table that has more dimensions.

Would a format along the lines of the following [1] suit you?

For a simple 1D table:

<table>
    <age min="31" max="33">
        <value>0.198</value>
        <value>0.194</value>
        <value>0.190</value>
    </age>
</table>


For 2D select table:

<table>
    <select period="3">
        <age min="31" max="33">
            <value>0.198</value>
            <value>0.194</value>
            <value>0.190</value>
        </age>
        <age min="31" max="33">
            <value>0.198</value>
            <value>0.194</value>
            <value>0.190</value>
        </age>
        <age min="31" max="33">
            <value>0.198</value>
            <value>0.194</value>
            <value>0.190</value>
        </age>
    </select>
</table>

Notice that I make the age/duration the inner-most axis, I think that's 
consistent with sample.database and is generally the most reasonable; please 
let me know if I got this wrong.

Another thing is that I prefer to make the axis name part of the markup (rather 
than using e.g. <axis type="select">). That's for validation: the latter 
couldn't have select-specific validation in XML Schema (analogous to the 
"version" attribute in the other schemas we discussed recently). Consequently, 
the order in which the axes are nested matters, you could have <age> at the 
higher level and <select> under it. I think that's A Good Thing, even for 
additional axes.

Speaking of which, this is what a TgCOI-like larger table would look:

<table>
    <smoker>
        <item for="smoker">
            <gender>
                <item for="female">
                    <select period="2">
                        <age min="31" max="33">
                            <value>0.198</value>
                            <value>0.194</value>
                            <value>0.190</value>
                        </age>
                        <age min="31" max="33">...likewise...</age>
                    </select>
                </item>
                <item for="male">...likewise...</item>
                <item for="unisex">...likewise...</item>
            </gender>
        </item>
        <item for="nonsmoker">
            <gender>
                <item for="female">
                    <select period="2">
                        <age min="31" max="33">...likewise...</age>
                        <age min="31" max="33">...likewise...</age>
                    </select>
                </item>
                <item for="male">...likewise...</item>
                <item for="unisex">...likewise...</item>
            </gender>
        </item>
    </smoker>
</table>

Notice that I didn't use <item for> under <select> in my previous example, 
because <select>'s child are well-defined: <select period="N"> has N child 
<age> (or <duration>?) elements for sequential select values of 1, 2, ..., N. 
Likewise for <value>s under <age>, the min and max attributes describe them 
sufficiently.

The order and enumeration values for the "smoker" or "gender" axes, on the 
other hand, are not so clear [2]. And even if there is some universally used, 
commonly understood order in the field, the order in the states enumeration is 
simply unrememberable and no human reader could make sense of it when studying 
a sub-table in the middle of that long list. For that reason, I prefer 
explicitness here: use <item> with the enumeration value to which the subtable 
under it applies.

This has the side-effect of making it possible to omit some values (e.g. have a 
table for only male & female data). Is that desirable? (If not, it's easy to 
forbid it in the schema.)

What do you think? Did I miss something important?

Thanks,
Vaclav


[1] Never mind minor details such as exact naming of the nodes (e.g. I suspect 
<gender-axis> etc. may be better than <gender>), I'm more worried about the 
overall structure.

[2] I'm sure the values of "gender" are obvious to you and the values "unisex" 
or "unismoker" only surprise outsiders and only briefly.