-
Notifications
You must be signed in to change notification settings - Fork 232
Web conference notes, 2021.07.08 (Joint Working Group)
Michael Schnuerle edited this page Jul 21, 2021
·
11 revisions
Joint Working Group
- Every week call at 9am PT / 12pm ET / 6pm CET
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)
Note: We are now collecting attendees upon entry into the Zoom meeting. A count will be posted after the meeting.
18 Attendees
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
- General structure change to define 'Programs' an agency is running
- Specify optional parts of any API, not just MDS. Eg, GBFS for now
- Use of vehicle types for now per Program, but would switch to modes when those are created and included.
- 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
- 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
andpolicy_document_url
have name collisions with the MDS Policy concept, suggestion to rename them toprogram_website_url
andprogram_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
?
Action Items
- Provider feedback on optional fields
- Discussion about making required fields disallowed
New Attendees
N/A
MDS Links
Working Groups
2.1.0 Release
0.4.1 Release Planning Meetings