Decide how to deal with extras

[vitorbaptista]

Currently we put the extras inside the root-level of the datapackage.json. That's good, because we set the pattern of putting in extras whatever we don't recognize, but it also creates an issue: what if an extra's key clashes with a datapackage key? For example, what if there's an extra with a key "sources"?

CKAN validates that there're no extras with keys that clashes with its values (e.g. name, author, etc.), but there're many fields in datapackage that have different names (or don't exist) in CKAN (e.g. sources and license), so CKAN doesn't prohibits them.

We could either add those validations ourselves or not add the extras into the datapackage.json's root level. I would rather not add validations, so I'm thinking the second option is the best. The issue is that when we import a datapackage with, say:

{
    "name": "gdp",
    "last_updated": "2011-09-21"
}

There's no field in CKAN for last_updated, so it must go inside extras. Then, when we export the created CKAN dataset, it'll become:

{
    "name": "gdp",
    "extras": {
        "last_updated": "2011-09-21"
    }
}

I would prefer the exported datapackage to be the same as the imported one, but it would complicate the code, so it's probably not worth it.

97a5c3e