Re: [lmi] Terse list of valuable projects

[Greg Chicares]

On 2010-03-18 10:31Z, Vaclav Slavik wrote:
> On Thu, 2010-03-18 at 01:39 +0000, Greg Chicares wrote:
>> What I'm wondering is why no one seems to serialize this way instead:
>> 
>>     <item key="propC">
>>       <data>3 4 5</data>
>>     </item>
> 
> It's bad practice, you loose all the advantages of using XML compared to
> some other, more human-readable text formats. Having just a generic XML
> parser is no longer enough, the <data> field now requires interpretation
> and a tokenizer to parse it. You cannot manipulate the content as a DOM
> tree anymore. You cannot describe the data with schema languages and you
> cannot validate it. You cannot transform it with XSLT or point to (part
> of) the data with XPath. And you cannot display the data nicely with CSS
> or FO, either.

Okay. Thanks (and to Vadim as well).

You might wonder whether 'input sequences'
  http://www.nongnu.org/lmi/sequence_input.html
should be represented by one xml element for each year (they are sequences,
after all...aren't they?). The answer is "no", because then they couldn't
possibly DTRT. Consider a payment represented thus:
  10000 20; 0
identically for all cells in a census. If one cell is age 60 and another is
age 70, and the illustration terminates at age 100, then the 'input sequence'
resolves to two different numeric vectors. Both begin with twenty instances
of 10000, followed by N zeros, but N is 20 for age 60, yet 10 for age 70.
And that's just a simple example.

End users recognize that the same concept is being applied in different
contexts, and expect to express that concept in exactly one generic way,
relying on lmi to work out the details. So, really, 'input sequences' aren't
sequences: they're a notation for *describing* sequences.

Many years ago, I tried storing the plain vector in the input file, and
dynamically adjusting it when its context (e.g., age) changed. That proved
highly unworkable.