I think that the objective are to vague for making something concrete.

In a nutshell the objective is to represent a CSV dataset in JSON, with the assertion the first line gives us properties names.

Spl33n has started to work on this at D11.

represent the CSV as JSON is the action not the objective it is the functionnallity implemented

The objective quoted are

• to store it in MongoDB database
• to make the API able to use it, allowing to query a dataset

The need of a MongoDB is not raised for the moment.
The API is still not begin to be designed if any needed. No one know the format it will need.

in my opinion it fills a you aren't gonna need it functionnallity

Initial context of this task

Yes, it probably falls under the document assumption.

The document provides "But unless your project is very different from mine, you already have too much to do right now. Doing more now is a very bad thing when you already have too much to do.".

One of the concern here were to provide a concrete task to spl33n. It's probably be a bad management move to write the spec of a part of the API and to give it to implement to a contributor, before the general API architecture is well documented. That raises the concern to get a project manager for this project, and we approached Kumkum for this role, but they instead provided us with (valuable) documentation and notes about geography and maps.

We had a small discussions on the channel about API, but not document has bee consolidated for the results. In this discussion, it has been decided not to use XML in favour of more lightweight formats.

We used the dataset as a working example, and agreed data exchange will be in JSON. We also note datasets are often in CSV.

The general idea were the format documented in the task description should be the format our API want.

Action needed

We need to design and document the API in a working draft document to avoid such occurrences.

We decrease priority for this task, as not currently vitally required by a specific project.

At this time, we've discussed about offering a converter online at Nasqueron Tools and to use it to fill Anuta (a CLI upload script for Wikimedia Commons, which wants CSV files).

Scope

So I'm revamping the task to give it a scope.

We want:

1. to solve the problem generic data headings should be transformed on universal alphabetic key identifiers
2. provide a library to use this key pattern
3. offer a reference implementation with a CSV to JSON converter to show this in practice (and nothing more as long as no real need for example from the API spec is decided)

I did not understood, it was an easy task. It totally changed my mind and find it well fitted.

I have reserve concerning the format. As it is intended to be treated as tabular data, I think the following would be more suitable

{
   "headers": ["Timestamp","Name","Age"]
    "data": [ ["4/11/2013", "Raymond Herisse", "22"],
              ["4/11/2013", "Gil Collar", "18"],
              ["4/12/2013","Stanley LaVon Gibson", "43"] 
            ]
 }

This format has the additional property to be more compact either plain or compressed.

Note that in either format there is no reason that the age is converted to integer.