Enhancement request: 'Native' importing of '.CSV' files

[Mike or Penny Novack]

I just want to point out what .cvs support entails for the benefit of 
those for whom this isn't immediately obvious.

.cvs refers to the low level format of the data -- just that the file of 
data consists of "records? delineated by <newline> and the records 
consist of "fields" delineated by commas. But there is nothing defining 
what data is in these fields and just as important, in what order.

That means that an "import from .cvs" functionality requires more than 
just being able to accept data separated by commas. It needs a facility 
where the user gets to enter information specifying which fields to be 
included (and which possibly ignored) and in what order. That's the 
substantial component of a project to "import from .cvs". Especially 
since without a "guide" for the user on using* this "field specification 
component" likely to be beyond the abilities of many "end users".

Michael D. Novack, FLMI


* keep in mind that it's not SIMPLY "using" (how to specify the skipping 
fields and reordering fields. The "end user" is unlikely to know 
(initially) what are the required fields and their order.

PS -- in it's simplest form, .cvs is an example of "positional;" rather 
than "keyword" data. However it is entirely possible that "keyword" type 
data could be stored in commas separated format (alternate fields are 
"field identifier" followed by "field data"). If the data is of that 
sort you don't need a field skipping and field reordering facility (a 
program can use the field identifiers to determine the fields it wants 
to put where regardless of order). However that isn't strictly speaking 
"cvs. data" in spite of the way delineated by commas. In other words, 
.cvs data and .cvs file don't mean EXACTLY the same thing.