Align propulsion_types in provider/status_changes spec and .ReadMe

[ezmckinn]

---

name: Emmett McKinney about: Suggest changes to MDS title: Aligning "propulsion_types" in provider/status_changes spec with ReadMe.

---

Explain pull request

The ReadMe for provider/status_changes.json 1.0.0 and the spec appear to conflict on the deprecated 'propulsion_type' field. We suggest renaming the propulsion_type object to propulsion_types (i.e., adding an 's'), replacing the $id reference with an enum[], and removing the existing propulsion_types object.

Is this a breaking change

• Yes, breaking

Impacted Spec

• agency
• provider

Additional context

The competing fields begin at Line 127 of provider/status_changes.json and Line 138, respectively. This caused some confusion for us while validating our Provider feeds.

[CLAassistant]

All committers have signed the CLA.

[thekaveman]

Thank you for the feedback @ezmckinn. A few issues with the proposal:

First and foremost, any changes to the JSON Schemas need to originate in the templates and/or generator code, which are found under the schema/ directory. The schema files sitting in top-level agency/, provider/ etc. directories are generated files and should not be edited directly.

These proposed changes were made against the common definitions; the actual status_changes schema is a few more lines down and (correctly) references the propulsion_types definition, matching the README: here in the list of required properties and here in the properties.

We split "item" and "array" definitions in a few other places, including UUID/UUID array, vehicle_type/vehicle_types, vehicle_event/vehicle_events ... again these are all in the definitions, to be composed by the schema generator code into the actual schemas in various ways.

Finally, enum is not a valid JSON Schema property with type: array. To restrict the items that can be in the array, the items property is needed, something like:

{
  "type": "array",
  "items": {
    "enum": [ ... ]
  }
}

See https://json-schema.org/understanding-json-schema/reference/array.html

Can you give a little more context about the trouble you were having validating your Provider feeds? We may need to update these definitions! Some clarity around the issues would help us target the right place to make the updates (templates, generators, etc.)

[schnuerle]

Since this looks to be breaking, and requires some more clarification and discussion, I'm going to mark this as a future 2.0 release item, unless things change in the next few weeks for 1.2.

[ezmckinn]

Hi Michael,

Thanks — this seems fine to me.

Best, Emmett

On Wed, Jul 21, 2021 at 11:16 AM Michael Schnuerle @.***> wrote:

Since this looks to be breaking, and requires some more clarification and discussion, I'm going to mark this as a future 2.0 release item, unless things change in the next few weeks for 1.2.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openmobilityfoundation/mobility-data-specification/pull/630#issuecomment-884272000, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALM5CUWZ55SB6LJYVSWN3FTTY3QEXANCNFSM4YUAAE2A .

[schnuerle]

Hi could you all leave your thoughts on this PR now to see if we can work this in 2.0 ASAP? It may be ok to work into the Modes work.

[thekaveman]

@schnuerle IMHO this PR should be closed / rejected. The change being proposed is not correct. The spec and the README do align, this person was confused reading the JSON Schema.

[schnuerle]

@schnuerle IMHO this PR should be closed / rejected. The change being proposed is not correct. The spec and the README do align, this person was confused reading the JSON Schema.

Ah I see what you mean, agree.

@ezmckinn we will be upgrading the JSON Schema to OpenAPI for 2.0 as well, so this change isn't needed.