lmi
[Top][All Lists]
Advanced

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

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


From: Greg Chicares
Subject: Re: [lmi] Calculation summary XML resources structure (with some examples)
Date: Sun, 29 Oct 2006 16:53:34 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

[manually reformatted to unbreak long lines]

On 2006-10-29 14:46 UTC, Evgeniy Tarassov wrote:
[message quoted is http://lists.gnu.org/archive/html/lmi/2006-09/msg00020.html]
[On 2006-9-26 14:47 UTC, Greg Chicares wrote:]
[> On 2006-9-26 13:20 UTC, Vadim Zeitlin wrote:]
>> > 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?
> 
> The following is a snippet from schema.xsd describing (and checking)
> double values formatting.
> 
> Could you please have a look at it (especially on the regular
> expression patterns below in xs:restriction node)? These expressions
> should be used to verify the correctness of the generated ledger xml
> data.
> 
>        <xs:annotation>
>            <xs:documentation>
>                [...]
>                | Formats
>                |
>                | f0: zero decimals
>                | f1: zero decimals, commas
>                | f2: two decimals, commas
>                | f3: scaled by 100, zero decimals, with '%' at end:
>                | f4: scaled by 100, two decimals, with '%' at end:
>                | bp: scaled by 10000, two decimals, with 'bp' at end:
>                |
>                | Presumably all use commas as thousands-separators, so that
>                | an IRR of 12345.67% would be formatted as "12,345.67%".
>                |
>                | So the differences are:
>                |   'precision'      (number of decimal places)
>                |   'scaling factor' (1 by default, 100 for percents, 1000 for 
> 'bp')

'bp' has not yet been implemented, but should be--someday. Its
scaling factor would be ten thousand, not one thousand.

>                |   'units'          (empty by default, '%' for percents, 'bp' 
> for bp)
>                | and therefore f0 is equivalent to f1
>            </xs:documentation>
>        </xs:annotation>
>        <xs:restriction base="xs:string">
>           <!-- update this regular expression for every change in formatting 
> rules -->
>           <xs:pattern value="(-?[1-9][0-9]{0,2}(,[0-9]{3})*)|0" /><!-- f0 -->
>           <xs:pattern value="(-?[1-9][0-9]{0,2}(,[0-9]{3})*)|0" /><!-- f1 -->
>           <xs:pattern value="((-?[1-9][0-9]{0,2}(,[0-9]{3})*)|0)\.[0-9]{2}" 
> /><!-- f2 -->
>           <xs:pattern value="((-?[1-9][0-9]{0,2}(,[0-9]{3})*)|0)%" /><!-- f3 
> -->
>           <xs:pattern 
> value="((-?(([1-9][0-9]{0,2}(,[0-9]{3})*)|0)\.[0-9]{2}))%" /><!-- f4 -->
>           <xs:pattern 
> value="((-?(([1-9][0-9]{0,2}(,[0-9]{3})*)|0)\.[0-9]{2}))bp" /><!-- bp -->
>        </xs:restriction>

At a glance, I don't see anything obviously wrong with that
translation of the original hardcoded formats to regexes. To
guarantee that would require rigorous testing.

However, I think hardcoding the formats was a poor idea in the
original design. For example, in HEAD, 'ledger_xml_io.cpp' says:

  // TODO ?? The precision of 'InforceLives' and 'KFactor' is inadequate.
  // Is every other format OK?
      format_map["InforceLives"                      ] = f2;
      format_map["KFactor"                           ] = f2;

Instead of using schema validation to enforce an obsolescent
paradigm that was too restrictive and inexpressive--and updating
the schema every time we need to be more expressive--I had hoped
we could use a new paradigm that's designed for the flexibility
we'd really like to have:

[http://lists.gnu.org/archive/html/lmi/2006-09/msg00005.html]
On 2006-9-14 16:19 UTC, Greg Chicares wrote:
| On 2006-9-13 14:21 UTC, Vadim Zeitlin wrote:
|> 3. Create another XML file containing the information about the columns
|>    (their names, titles) and format of the data. Currently it would have
|>    to be modified manually if the required report format changes but the
|>    plan is to allow customizing it from the GUI in the future (i.e. add
|>    a "Report format" dialog which would generate this XML file dynamically)
|
| I agree.
|
| Right now, four formats are hardcoded:
|   {[0 | 2] decimals, [true | false] show-as-percentage}
| That's not as flexible as it should be. Any number of decimals
| in [0, DECIMAL_DIG] should be permitted. We might also allow data
| to be displayed as "basis points" (hundredths of a percent), at
| least as a future extension.

[A footnote to the first message quoted above explains why
DECIMAL_DIG should be twenty-one.]





reply via email to

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