[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] actuarial tables format (was Re: Terse list of valuable projects)
From: |
Václav Slavík |
Subject: |
[lmi] actuarial tables format (was Re: Terse list of valuable projects) |
Date: |
Wed, 21 Mar 2012 19:24:49 +0100 |
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.
- Re: [lmi] Terse list of valuable projects, Greg Chicares, 2012/03/12
- [lmi] actuarial tables format (was Re: Terse list of valuable projects),
Václav Slavík <=
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Greg Chicares, 2012/03/21
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Vadim Zeitlin, 2012/03/21
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Greg Chicares, 2012/03/21
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Václav Slavík, 2012/03/22
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Vadim Zeitlin, 2012/03/22
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Václav Slavík, 2012/03/22
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Greg Chicares, 2012/03/24
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Václav Slavík, 2012/03/24
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Greg Chicares, 2012/03/24
- Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects), Václav Slavík, 2012/03/24