Re: [lmi] calculation summary, questions about xslt

[Greg Chicares]

On 2006-10-10 0:23 UTC, Evgeniy Tarassov wrote:
> 
> 1) illustration_reg.xsl

Someday we'll want to rewrite all the '.xsl' files that are in cvs
today. They aren't what we actually distribute to end users: for
production, we distribute different files that are not under version
control. That's not an ideal situation, of course, and in the long
term we want to change it.

For now, however, that's just not possible, so we need to focus on
the calculation summary.

You've pointed out some real problems with those files; I guess
validating them against a schema makes the problems evident. That's
valuable information for us to use later.

> 2) html.xsl
> 
> 2.1 the code generating html contains an expression
> 
> (is_subject_to_ill_reg(ledger_values.GetLedgerType()))
> 
> Do you think that (in xslt) we could express it using values already
> exported into xml. Or should we export additional named value?
> (another double_scalar value maybe?)

Is this a unique situation? If there's only one value like this
(or only a few), then I'd agree: it's best to export an additional
value to xslt.

When we were doing everything in C++, it was sensible enough to
segregate this logic into one function (which is used in the input
code as well). We can just call that function when we create data
to pass to xslt.

> 3) schema.xsd
> 
> 3.1 do we want to separate string_ nodes from double_ nodes?
> (string_vector and double_vector)
> 
> Keeping strings and (already formatted) numbers in different type of
> nodes we could inforce addiotional checks onto the xml data geenrated.
> I have added regular expression based restrictions on the values a
> double_scalar could get.

Here's where I think we left it:

http://lists.gnu.org/archive/html/lmi/2006-09/msg00020.html
|
| VZ: > In this case we'll need to slightly modify the XML schema (to merge
| VZ: > double_scalar and string_scalar tags).
|
| GWC: Perhaps we should leave them alone after all, to help preserve
| GWC: the possibility of gaining the advantages of option (2) later?

At first, I had thought that this type distinction would only
complicate your work unnecessarily; but then I think you and Vadim
showed me that it is actually advantageous (because it enables
stronger validation) and doesn't make your work harder. As long as
I've portrayed your viewpoint correctly and you still think it's a
good idea, then my answer is "Yes", you've persuaded me.

> 4) tab_delimited.xsl
> 4.1 the code generating CSV formatted data contains some code checking
> that e_run_curr_basis_sa_zero is present in
> ledger_values.GetRunBases().
> 
>        std::vector<e_run_basis> const& bases(ledger_values.GetRunBases());
>        if
>            (   bases.end()
>            !=  std::find(bases.begin(), bases.end(),
> e_run_curr_basis_sa_zero)
>            )
>            {
> 
> Do you think there is already some way to check that using the already
> exported values?

First of all, this is similar to
> 1) illustration_reg.xsl
above in that it's not part of the calculation summary, so it's not
a top priority. But it's different in that PrintFormTabDelimited(),
the function you're quoting here, really is the production version,
so you do have enough information to replace it. And, while it is a
lower priority than the calculation summary itself, it's extremely
valuable to replace it--and it makes a lot of sense to do it now,
because it's so similar to the calculation-summary work.

This seems somewhat similar to is_subject_to_ill_reg() as discussed
above. When it's all done in C++, all this data is available in the
'ledger' class, so there's no strong reason not to use it. But now
we need to take a fresh look. What's the best way to do this with
xslt?

PrintFormTabDelimited() is a free function with a Ledger const&
argument. It uses this accessor
  ledger_values.GetRunBases()
for some class Ledger member data that probably shouldn't be
exported as such. Let's analyze the uses.

        if
            (   bases.end()
            !=  std::find(bases.begin(), bases.end(), e_run_curr_basis_sa_half)
            )
            {
            fatal_error()
                << "Three-rate illustrations not supported."
                << LMI_FLUSH
                ;
            }

This is really just an assertion. It seems appropriate to keep
that code, and run it whenever data is prepared for transmission
to xslt. We actually do have code to support this case, and we
used to need it, but then the law changed. We may want to use it
again someday for some other purpose, so I didn't remove the code.
But I didn't want to spend any time figuring out how to handle
this case in PrintFormTabDelimited(), because we don't use it
today.

        // Show experience-rating columns for current-expense, zero-
        // interest basis if used, to support testing.
        std::vector<e_run_basis> const& bases(ledger_values.GetRunBases());
        if
            (   bases.end()
            !=  std::find(bases.begin(), bases.end(), e_run_curr_basis_sa_zero)
            )
            {/* print the actual data */}
        else
            {/* print zeros */}

Here, what's important is whether 'e_run_curr_basis_sa_zero' data
exists; if it didn't, there'd be a segfault. I understand C++ better
than I understand xslt, so I don't know how this would naturally be
handled in xslt; probably I'd better ask your advice.

If the data for that "basis" fails to exist, we really do want to
print zeros. The goal is to use exactly the same column layout in
all cases. Thus, for instance, we can produce tab-delimited files
for two products with different 'e_run_curr_basis_sa_zero' values,
paste them both into the same spreadsheet, and calculate ratios of
all columns, knowing that all the data lines up the same way.