Associated Trip Fix

[black-tea]

This breaking change addresses #88 for the associated_trip field in the status_changes endpoint.

Changes:

• Clarifies that associated trip is singular, not plural in provider README.md
• Modifies field name (associated_trips -> associated_trip) in JSON Schema and README.md
• Modifies JSON Schema from optional to required if applicable using implication logic
• Modifies JSON Schema type from array of UUIDs to single UUID

[oderby]

I'm a huge fan of this change (not surprisingly). I have one JSON schema question, otherwise this lgtm!

[oderby]

Is this just anyOf instead of oneOf because you can't specify oneOf twice for the same object? Not to get too far into the weeds, but wouldn't it be more semantically correct to structure this whole sub-schema as a single allOf with three sub-schemas: 1. the current oneOf defined above for valid event_type and event_type_reason combinations
2. this, as a oneOf, defining when associated trips is required
3. the rest of the properties, defined below.

More specifically, this would look like (non-relevant intermediate lines omitted for brevity):

"items": {
  "$id": ...,
  ...
  "required": [...],
  "allOf": [
    { "oneOf": [ "schema_for_valid_event_types_and_reasons" ] },
    { "oneOf": [ "this_schema_for_associated_trip" ] },
    { "properties": "...properties listed below...." }
  ]
}

(caveat this is the first time I've read the JSON schema spec closely, so take this with a dose of skepticism/it may be way wrong)

[oderby]

Also just realized - this file is auto-generated. I believe the one you want to change is https://github.com/CityOfLosAngeles/mobility-data-specification/blob/dev/generate_schema/provider/status_changes.json

[hunterowens]

Closing as this is supplanted in #217.