Add mode in trips and vehicles objects

[pierre-bouffort]

In the present data structure, the trips and vehicles objects have some fields that depend on the Mode (trip_attribute, journey_attribute, fare_attributes, ...). But currently, the trips and vehicles do not have a mode field. Therefore, to determine the mode of a trip for example, we have to retro-engineer it from the trip_attribute, journey_attribute, fare_attributes, ... fields. And sometimes it is not even possible to do so with a 100% accuracy.

=> This can cause some issues when trying to validate and store the data correctly.

[jiffyclub]

The expected mode of a data object can be determined from the provider_id. Per the spec "a provider implementing more than one mode shall register a unique provider_id for each mode." The providers.csv file contains the mode associated with each provider.

[kevin-courbet-blue]

Good point. Although this means that, in the context of processing a given document (trip, or vehicle registration), the document is not stand-alone, ie some details are hidden away until one cross references the providers table. While technically it is possible to cross-reference the providers table at runtime, I think it is safer/easier/more explicit if the property is part of the document itself. It is easier to implement because you know what shape the document is supposed to be just by looking at it. Although cross-referencing the providers table isn't too hard, it's still something extra to do that could be avoided. @pierre-bouffort fyi

[jiffyclub]

I vaguely remember a conversation in the development of MDS 2 where we explicitly decided not to include mode in data objects since it's duplicate information, both from the provider ID and because there's a 1:1 mapping between a mode and download URL. You have to add mode to pretty much every single data object in MDS if you go down this route, but I see the appeal.

[schnuerle]

Yes @jiffyclub is correct. We had a few discussions about this on GitHub and in working groups. The consensus was to store the mode info only in the providers.csv file, and not duplicate mode info again in the data, to avoid any potential conflicting mode info and not know which is the authoritative source.

If you can make a case for adding mode into the spec, you can get that conversation started.

[kevin-courbet-blue]

It just occurred to me that, at least in the case of OAuth2 (which our implementation uses), one could easily add a mode scope to the JWT on a provider basis (eg. providers/car_share), so if implementing this way, a round-trip to the providers dataset is not necessary (the mode will be available for each request).

I still think it would be beneficial for data structures to be "stand-alone" for easier processing down the road, but at least this isn't mandatory anymore, more like a strong recommendation. Our implementation adds that "mode" field to trip structs internally.

@pierre-bouffort fyi

[schnuerle]

I think we can close this issue, correct? The consensus is to use the providers.csv file to determine the mode and is the single source of truth.