Use `camelCase` instead of `kebab_case` in spec for consistency

[miguelrk]

Currently, the root properties of the spec use kebab_case for properties e.g. semantic_types and chart_spec while everywhere else the spec uses camelCase for properties e.g. chartType. This is inconsistent not only within the schema, but also with the usual convention for JavaScript/TypeScript which is to use camelCase (I understand kebab_case is the standard in e.g. python), but having both is definitively odd and confusing.

{
-  "semantic_types": {
+  "semanticTypes": {
     "count": "Quantity",
     "percentage": "Percentage",
     "region": "Category"
   },
-  "chart_spec": {
+  "chartSpec": {
     "chartType": "Scatter Plot",
     "encodings": {
       "x": "count",
       "y": "percentage",
       "color": "region"
     }
   },
   "data": {}
 }

Maybe I am missing something, there must be a valid reason? Additionally, we could maybe rename chartSpec to simply spec?

In any case, standardizing this to use camelCase for all properties would be more consistent and standard.

[Chenglong-MS]

Good call. This was a bit of a legacy issue that is carried over. We should switch to camelCase since everywhere else uses camel. Let me add this to the todo list.

[miguelrk]

That would be great Chenglong Wang (@Chenglong-MS)! What would you think about also simplifying and/or renaming the properties, especially those which may be redundant considering this is already a flint spec:

• chartSpec to simply spec, or something else like options/config? Or maybe even removing it and moving contents to root?
• chartType to simply type

These are just some that come to mind, there could be more...

[Chenglong-MS]

Some of these are a bit intentional, like chartSpec / themeSpec and others like interactionSpec etc. Would love to do a bit review and propose a spec v2.

In the original design, we were thinking about separating dataSpec (semanticTypes) from chartSpec (chartType + encodings). If you have any idea coming to mind, feel free to share!

[miguelrk]

Glad you are open to revisiting the spec for v2. I don't really have a proposal, just ideas like those proposed/dumped above. But if there is to be, as you mention, a chartSpec, themeSpec, interactionSpec, etc maybe the Spec is somewhat redundant, since we are already inside a flint spec, so maybe e.g. chart, theme, interaction, etc is clear enough. Regarding grouping related properties via top-level properties like these, I do think that makes it clear, but moving the main chartSpec properties to the root could also make it more minimal and more direct, since at the end of the day, the spec is already a chart spec, so this only introduces an extra level maybe? But obviously we would have to be careful about potential naming conflicts in the root...

Those are just some thoughts that come to mind.