Course Transcript Exchange SIG - Report Out

Owned by Eric Jansson
Last updated: Mar 02, 2020
2 min read

The recommendations of the Course Transcript SIG can be divided into 2 parts:

  1. changes relating to the data model, which would naturally flow to the API model
  2. proposal for a new, aggregate API structure designed to transmit an entire transcript as a single logical package

The SIG completed a recommendation of the #1 but did not complete a full recommendation on #1.

Data Model Changes

The entire set of data model changes recommended by the SIG can be seen in these UML diagrams:

Detailed discussion of all elements can be found in the SIG notes.

The main changes were designed to solve key issues related to the requirements that a Course Transcript entity have a Course reference, and gaps in the ability and flexibility of ways to sum up transcript credits, for the purpose of ascertaining progress towards one or more graduation plans or  of capturing key data when a Course reference may no longer be available (e.g. that a Course Transcript was for an IB, AP or dual-credit  course). A few smaller issues were also addressed.

These changes have been captured in these DATASTD tickets:

Note that some of the proposals are breaking, and that fact may affect how and when they are releases - please follow these tickets for details. The SIG noted a preferences to issue breaking changes on an annual cadence, when necessary.

Proposal for an Aggregate API

A second concept that was raised was to develop a new API that offers transfer of a student transcript as a single package. This concept has been captured in this ticket: 

The SIG agreed that this ideas was worthy of exploring, but a number of nuanced questions about the use case were able to be answered, leaving gaps in the ability to design fully the proposed package and API. Among these are questions such as:

  • is the API more for bulk transfer or more for individual transfer, or both?
  • does the API also envision including Course data?
  • what exactly should be included? everything? or some subset?
  • what happens when descriptors/option sets differ between the sending and receiving system (such as those for Credit Area)? is the assumption that the receiving system will first populate these?

The recommendation of the SIG is to explore the exact use cases and questions within the context of an actual field project.