Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants


Expand



First NameLast NameOrganization
MarcosAlcozerAlcozer Consulting
EmilioBaezEdufied
KathleenBrowningEd-Fi Alliance
DavidClementsEd-Fi Alliance
RoshDhanawadeEducation Analytics
JasonHoekstraEd-Fi Alliance
EricJanssonEd-Fi Alliance
DouglasLoyoEdufied
VinayaMayyaEd-Fi Alliance
GeoffMcElhanonEdufied
EsharaMondalEducation Analytics
AndrewRiceEducation Analytics
JimRifeESP
MarkTenHoorEducation Analytics
MustafaYilmazEd-Fi Alliance


Support: Ann Su, Ed-Fi Alliance

Agenda

  • Question on how to handle availability statements connected to badges and certification (David Clements)
  • Questions on ODS release timeline (Vinaya)
  • Assessment Rostering / Registration - summary of community activity and feedback + open discussion (Eric)

Materials

View file
nameAssessment Rostering - Summary.pptx
height150


Notes

Product availability

Net conclusion: pivot the product availability away from its current purpose and to product and service offerings that is more open-ended

  • add deployment types
  • add other services
  • make it positive in orientation
  • list product and service offerings

ODS / API timeline question

MSP feedback is to prioritize the schedule and release in November, rather than delay

Assessment Rostering

Chatty API not really a problem - this can be engineered around. 

States want to control what vendors can see - a composite/aggregate API helps you offload the intricacies of permissions

GraphQL is a possible solution

On authorization, there are 2 kinds of data over-exposure possible:

  • a client able to access students not part of the roster
  • extra data on those students that can be read from the granular API

There seem to be solutions to these authorization issues:

  • add an API authorization strategy that uses roster data
  • add an API profile that filters data in a "best practice" default way

Question on chatty API vs aggregate APIs and auth strategy implications is a TAG-level discussion 
Relates to the possibility of GraphQL

Is there a potential to use OneRoster?

  • Need to learn more from the vendor market practice today
  • It isn't clearly a fit for the core use case of OneRoster, at least not for the major interim providers (it is not classroom based and has more diverse demographics)
  • Raises same questions about a monolithic vs granular/chatty API

Actions

  • Eric to raise issue of API design to TAG
  • Eric to prep summary questions for Ed-Fi vendor outreach