Defaults in Messages JSON and Messages objects

I want to share my thoughts on this topic, as a kind of discussion forum here.

## Defaults in Messages JSON

As I worked a bit with the new messages structure, I would like to bring up (again) the problem of defaults in the messages protocol. Currently I have found 3 cases that were not fully consistent with my understanding:

* Scenario[/Background/...].description
* Scenario[/Background/...].name
* TableCell.value

These are currently set as required in the JSON schema, although they are optional in Gherkin and in many cases they are usually not provided (e.g. I have never seen anyone adding a name or description to a Background, but also Scenario description is rarely used). Forcing ourselves to include a dummy empty setting for them in the messages JSON files seems to be unnecessary for me.

As far as I have understood @aslakhellesoy, the original intention was to populate these properties for dynamic languages, but with TS this does not seem to be necessary anyway.

A similar question could be raised for the empty arrays, but those are more correct semantically.

Location.column is currently set as optional (inconsistency with the others)?

Also I feel that if we make "set everything as required" as a rule for the messages JSON, then if later we introduce a new (optional) setting (and make it required by following our rule) then the old JSON message files will became invalid according to the schema, so it will be harder to introduce non-breaking changes.

So my questions are:
* Shall we make these mentioned string fields optional in the JSON schema?
* Shall we make the arrays optional in the JSON schema?

## Defaults in Messages objects

If we would make these settings as optional in the JSON schema, we could still think about the default value that we use in the populated message objects if the particular field was not specified. As far as I know JSON schema does not provide an option to explicitly specify the default value, so this can only be an agreement that the different implementations follow.

I think here there are 3 questions:

* What should we use as default value for not-provided optional **strings** (empty string or null)?
* What should we use as default value for nor-provided optional **arrays** (empty array or null)?
* What should we use as default value for nor-provided optional **numbers** (0 or null -- for null we need to represent it as nullable number in the objects for static type languages)?

What do you think?