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

[Greg Chicares]

Let me address the crucial question--where numeric formatting
should be done--in a separate message later, after first
answering some of the easier topics here.

On 2006-9-25 16:16 UTC, Evgeniy Tarassov wrote:
> 
>> I am pretty confident that names are globally unique, so that a
>> 'scalar' and a 'vector' can't share the same name. I'm not sure
>> that the program enforces that global uniqueness--maybe it's been
>> just a matter of programming discipline to avoid it--but it would
>> probably be a good idea to enforce it, eventually, just to make
>> sure it's a perfectly reliable invariant.
> 
> It will be really nice to be able to check that double scalars has numeric
> data, therefore that distinction between double_scalar and string_scalar.
> Our Schema would include a uniqueness constraints for sure. We have
> put couple of TODO mentioning name uniqueness problem. Using XMLSchema
> we can enforce that a group of parameter values (name and basis
> attributes in our case) is unique across the nodeset specified (all
> the double_scalar, string_scalar and vector nodes at the same time).

I am not opposed to distinguishing numeric and string data. Maybe
it would be less useful to maintain that distinction if we choose
to do all number formatting in C++, but I wouldn't oppose keeping
the types distinct even in that case if you still think it's a
good idea.

>>         <duration number="54" column_value="20,000"/>
>> and I'd just like to mention that, for 'fop' at least, we really
>> do need to select certain durations sometimes. For instance,
>> normally we print every column in its entirety, but there's a law
>> that requires us to show something like the tenth value, the
>> twentieth, and the one corresponding to age seventy. Does that
>> remain possible if we omit 'number='? Here, again, the schema
> 
> Say we want to reference a 17th of 'AcctVal' vector. The corresponding
> XPath expression would be:
> If we use the current XML structure with "number" attribute:
> /illustration/address@hidden'AcctVal']/address@hidden
> For the proposed XML structure:
> /illustration/address@hidden'AcctVal']/duration[position()=17]

The second expression uses only three more characters, but lets
us save many redundant characters in the data file.

> The expressions are fairly similar (ofcourse given that vector values are
> always kept in the same order and index is 1-based).
> If at any point during fo-transformation we will need that index, then
> we could always reinject that position() value into data.fo using
> fo.xsl transformation or we could still get the value using XPath
> function position(). The expression syntax does not suffer at all
> while the data.xml file could be slightly simplified (smaller in size
> and more human-friendly).

Yes, I agree: 'position()' is a win.

>> names in the program; I don't know whether that has any real
>> benefit, and I imagine that the same effect could be achieved
>> by making an empty 'spacer' available.
> 
> Sorry i have missed that feature. Either specifing an empty element in
> supplementalreport section or introducing a new node 'spacer' will do
> the same thing. Maybe your idea of 'spacer' is better than an empty
> <column /> element because it's more explicit than a "empty column
> means a spacer" rule. Let us know what do you think is better aligned
> with lmi philosophy and we will modify schema and *.xsl files
> accordingly.

Menus expressed in '.xrc' files already use
  <object class="separator"/>
I think we should use that same word for consistency, so that we
don't have to remember to say 'separator' in one context and
'spacer' in another.