data design

[James Stroud]

BJörn Lindqvist wrote:
> On 1/31/07, James Stroud <jstroud at mbi.ucla.edu> wrote:
>> [copy_files]
>> files_dir1 = this.file that.file
>> path_dir1 = /some/path
>>
>> files_dir2 = the_other.file yet_another.file
>> path_dir2 = /some/other/path
>>
>> In yaml, it might look thus.
>>
>> copy_files :
>>       - files : [this.file, that.file]
>>         path  : /some/path
>>       - files : [the_other.file, yet_another.file]
>>         path  : /some/other/path
>>
>> Both are readable (though I like equals signs in appearance over
>> colons), but yaml doesn't require a lot of string processing to group
>> the files with the paths. I don't even want to think the coding
>> gymnastics required to split all of the option names and then group
>> those with common suffixes.
> 
> But is not that a perfect world example? Consider:
> 
> [copy_files]
> files_dir1=this.file that.file
> path_dir1=/some/path
> files_dir2=the_other.file yet_another.file
> path_dir2=/some/other/path
> 
> versus:
> 
> copy_files:
> -files:[this.file,that.file]
> path:/some/path
> -files:[the_other.file,yet_another.file]
> path:/some/other/path
> 
> Mandatory indentation is good in programming languages, but does it
> really belong in configuration files? With tabs verboten to boot.
> 

I'm not sure whether to agree with you or disagree with you. My 
conclusion is that if it is at all possible, try to use an ini file, 
even if you have to stretch your imagination a bit. More complex formats 
are prone to one's assigning some imperative meaning to the structure 
(as I am doing with my example, which might make it a bad one). However, 
these more complex formats can intensely useful for (1) knowledgeable 
people with (2) complicated data.