Data structure with sub-objects for mode-specific attributes complexifies the data ingestion

As of today, objetcs such as trips and vehicles have in their fields some attribute tables that depend on the mode they relate to. We find this structure to be sort of sub-optimal. Indeed, as explained in the scheme below, we believe an alternate option could be to define the fields in the objects themselves (trips, vehicles, ...) as conditional to the mode.

In practice, this would mean to include the fields in these mode-specific attribute tables (like trip_attributes, vehicle_attributes, ...) directly into the root objects (trip, vehicle, ...) and defining their required/conditional status based on the mode itself.

=> Instead of having objects with mode-specific fields, you end up having mode-specific objects.

PS: this would be made possible only if the mode is written in the object, see Issue #887

Start by reviewing Issue #887, since this proposal depends on mode being present in each object. Compare the current trips and vehicles structures, including trip_attributes and vehicle_attributes, with the proposed mode-specific objects. Done would be an agreed schema direction that clearly documents the resulting fields and conditional requirements.