TAG Meeting 2015-10-07

Owned by Eric Jansson (inactive account)
Last updated: Oct 16, 2015
3 min read

Attendees

  • Mark Walls
  • Duy Nguyen
  • Don Dailey
  • Reese Robinson
  • Satish Pattisapu
  • Josh Klein
  • Erik Gomez
  • Neal Schuh
  • Geoff McElhanon
  • Josh Allen
  • Chris Moffat
  • Eric Jansson

The meeting opened with some housekeeping including an announcement that the November meeting would be moved a week later, and a call for any new agenda items for the current meeting. No new items were proposed.

The meeting reviewed design work on the composite API work that was an outcome of the 2015 “Vendor-to-vendor” workshop in Austin TX. The item followed the prepared Powerpoint deck and the following topics were discussed:

 

Should the resources exposed by composite APIs have the same requirements as the Ed-Fi data standard?

The current concept was that data fields for resources should follow the data standard (i.e. a DoB is required for Student). There was some limited input on this topic. One compelling idea was that the combination of Profiles (data access policy) with Composites offers a solution by allowing the client to specify more limited data profiles where needed. This would help keep Composites APIs data-richer, while also providing a means for simplification in the field where needed.

 

The Ed-Fi data model uses descriptors to allow for local terminology. How should these be handled?

There was considerable discussion on this topic and it was agreed that this is a difficult problem many systems face. The general input seemed to be that some amount of standardization for enumerations on a set of canonical values was important, and that allowing for variable display resolves many of the issues. The main reason cited for this is that canonical values are important to data semantics: unless you can have agreement on what certain values mean across systems, messages cannot be interpreted accurately.

 

Resource modeling - APIs model resource hierarchies – how should composites model the hierarchy?

The general input was to go for an MVP, keep it simple, and drive it by use cases that are clearly defined. The need to consider common navigation pathways was raised, but the general sense was that it was better to force clients into some amount of multiple calls to an API rather than to try to support all pathways or have a lot of convenience methods. Be more prescriptive about access patterns rather than more open.

The general advice from those who spoke was also to avoid lots of convenience supports, such as filtering, searching or field selection, except where important for other reasons (see below).

Some questions about how an Ed-Fi API would support composite primary keys / natural keys were raised. While nothing conclusive emerged, it was suggested that simpler key:pair values as parameters can be helpful in APIs.

One possible design resources that was raised was the Digital Services Playbook, which provides API guidelines for government entities. The Alliance will consult this in further design work.

 

Does the Roster API consider existing K12 Roster API designs?

Those who contributed on this point in general said that yes, attempts should be main to coordinate, both at an API level, but also overtures to coordinate sector activity on this. The fundamental reason is that support for multiple standards introduces expense.

 

What are the fundamental use cases of the Ed-Fi Assessment API?

The following use cases were suggested:

  • Getting formative assessments from those source systems into a district gradebooks
  • Assessment data movement between gradebook systems
  • Movement of grade data from source systems to separate “report card” tools
  • Allowing teachers to get access to benchmarks in advance of student conferences
  • Moving assessments between different school districts