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

[pierre-bouffort]

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

[schnuerle]

Great write up and I remember having some conversations about what this structure should be. I can see benefits/cons to the way it is now and your proposed new way. With your proposed way you could take it a step further: the 'common fields' could just be moved up to a higher level above the mode, and the acc/fare/trip attributes could be per mode - just as another way to slice it.

Trip
   ( Common Fields)
   Passenger Services Trip
      ( Passenger Services acc/fare/trip attributes )

Of course a change like this would hit a future MDS 3.0 release as it's breaking.