Re: [lmi] Calculation summary XML resources structure (with some examples)

[Greg Chicares]

On 2006-9-26 13:20 UTC, Vadim Zeitlin wrote:
> On Tue, 26 Sep 2006 05:24:37 +0000 Greg Chicares <address@hidden> wrote:
> 
[Numeric formatting where? (1): C++; (2): xslt...]
> GC> I see the arguments in favor of (1) as stronger, especially because
> GC> it's already in place and has less risk. Do you strongly disagree?
> 
>  No, I don't disagree strongly. I still think it would be conceptually
> better to do the formatting in XSLT

Thank you for expanding upon that in the part I've snipped here.
I recognize that there are good reasons for both approaches.

> and I'd prefer to do it if I were sure
> to not have any problems with (F) and, to lesser extent, (D). But in the
> current situation and taking into account the other points I think it's
> perfectly understandable to choose to do the formatting in C++.

Okay, then let's do that.

>  We just need to understand clearly that our XML data files won't be the
> primary source of the calculation data but just an intermediate step
> between the C++ code generating this data and its output representation
> (this could be important if we also wanted to use these XML files for data
> exchange, for example).

Because there are valid arguments in favor of (2), does it make
sense to try to maintain the possibility of switching later? I
think we could do that by

 (a) making C++ emit floating-point data in only one format,
     designed for robust data interchange--probably scientific
     notation with 21 digits [1]--and maybe eventually removing
     the support for other formats; and

 (b) migrating the existing C++ formatting code to xslt.

I know we can do (a); would it take a lot of effort to leave the
door open to (b)?

> And we also will need to make sure that C++
> formatting routines are as configurable and flexible as possible to
> minimize the changes to this code in the future when a need for other
> output formats arises.

I can take care of that. Existing formats vary in few ways:
 - number of decimals: 123.456 --> "123.45", e.g.
 - percentages:            0.5 -->    "50%", e.g.
to which we should probably now add
 - thousands separators:  1234 -->  "1,234", e.g.
and those variations can be expressed in an xml file so that we
never need to recompile to change them.

> But if neither of these points is a real problem,
> then, practically speaking, C++ approach does seem to be more appealing.
> 
>  Could you please definitely confirm that this is what we're going to do?

Yes. I definitely confirm that.

> In this case we'll need to slightly modify the XML schema (to merge
> double_scalar and string_scalar tags).

Perhaps we should leave them alone after all, to help preserve
the possibility of gaining the advantages of option (2) later?

> Also, are there any other changes to
> be done or should we consider these formats accepted and continue with the
> next stage of the work?

I...think so, but I guess you need a definitive final blessing,
so let me analyze this carefully. Just to be clear, I think the
formats are pointed to by Evgeniy's 2006-09-21T12:32Z posting:

| schema.xsd - a Schema file describing illustration data (data.xml) and
| column traits file (format.xml)
|
| data.xml - an example of illustration data
|
| format.xml - an example of a column traits file
|
| html.xsl - a working example of an XSL template generating a report in

and exactly which of those should I formally sign off on now?

---------

[1] "21 digits": C99 5.2.4.2.2/13 says "if the widest type
were to use the minimal-width IEC 60559 double-extended format
(64 bits of precision), then DECIMAL_DIG would be 21."