Web conference notes, 2021.07.08 (Joint Working Group)

Web Conference, 2021.07.08

Joint Working Group

Every week call at 9am PT / 12pm ET / 6pm CET

Conference Call Info

Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Attendees

Note: We are now collecting attendees upon entry into the Zoom meeting. A count will be posted after the meeting.

18 Attendees

Agenda

Main Topics

Policy Program Requirements API Updates - work session continued
- Work on getting Requirements over the finish line and resolving open issues.
- Review most recent changes based on feedback in last meeting
  1. General structure change to define 'Programs' an agency is running
  2. Specify optional parts of any API, not just MDS. Eg, GBFS for now
  3. Use of vehicle types for now per Program, but would switch to modes when those are created and included.
  4. Clarify that required parts of specs are still required. This only lists the optional items.

WGSC Meeting Organizers

Host: Steve Brining
Facilitator: Angela Giacchetti
Outreach: Michael Schnuerle
Note taker: Matt Davis

Minutes

Introductions from new steering committee members
Michael Schnuerle reviewing updates to https://github.com/openmobilityfoundation/mobility-data-specification/pull/646
- Added concept of agency "programs" that can have different policies and metadata
- Within each program agencies can specify required specs and required endpoints and data within those specs
- What are the implications of allowing agencies to make some "optional" fields from MDS required within their programs? How onerous will that be for operators? Need input from operators.
  - TO DO: tag operators and ask for feedback on issue 608
- Do we need a notation for specifying required fields, e.g. the name of a potentially nested field within an endpoint. The suggestion of dot-separated field names seems reasonable.
  - DONE: Added dot notation to PR
- "version" for file version of requirement file is confusing
  - DONE: renamed to 'file_version' in PR
- What does it mean to have agency hosted APIs listed as a required API within a requirement program? Maybe a separate section for those? available_endpoints?
  - Available agency endpoints initially informational, but we have the option to specify required usage in the future.
  - DONE: added available_endpoints and related terms to PR
- policy_website_url and policy_document_url have name collisions with the MDS Policy concept, suggestion to rename them to program_website_url and program_document_url.
  - DONE: updated in PR
- Specifying the ID of an MDS policy within a program has some downsides, mainly because policies are immutable and updating a policy would create a new ID and the Requirements file would need to be updated... Do we want the Requirements endpoint to be that malleable/is that a big headache for agencies? Proposal to remove the policy_id field from programs and letting policy discovery happen in some other, unspecified way.
  - Note that sometimes policy is used to mean program in MDS, and it's a weird thing at times
  - DONE: removed from PR
- Is providing an unrequested optional field within an API response out of spec? Questions around expectations related to fields that are marked optional in MDS and who decides whether to include them.
  - TO DO: need discussion about this on issue 608
  - How to specify fields that shouldn't be included in API responses? disallowed_fields?