[Top][All Lists]
[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.]