Ordering of interchanges leads to dependency cycles

Summary of outcomes for Data Standard 2.1

• Problem Addressed: LearningObjective and LearningStandard are included in multiple interchanges, creating dependency cycles.
• High-level Reasoning: When an entity is included in multiple interchanges, cyclical references may be created, making it impossible to determine the correct interchange load order. Additionally, the LearningStandards domain is inconsistently named (Interchange is named "Standards").
• Changes Made: Change LearningStandard and LearningObjective references in the AssessmentMetadata and StudentGradebook interchanges to use identity references; Rename LearningStandards domain "Standards"

Original ticket description follows:

Taken from METAED-544:

The basic premise of ordering interchanges here is not always feasible given the flexibility we give implementations right now. Even the more granular case of ordering all top level entities can run into issues of circular references. This is currently a theoretically insurmountable issue, which can only be resolved by adding additional validation to enforce more restrictive patterns on the end user. Typically a data model shouldn't have these sort of loops on dependencies anyways, but we would need to add validation to detect and inform the user about them if they were added in the future, particularly around extension use cases.

The core issue with the current 2.0 Data Standard is that there are dependency cycles due to LearningStandard and LearningObjective. LearningObjective exists in the Standards, AssessmentMetadata, StudentGrade, and StudentGradebook interchanges, where LearningStandard exists in the Standards and AssessmentMetadata interchanges. This is due to the current support for an entity to exist in multiple interchanges. The problem is this can cause cycles in references, which gets in the way of determining the correct interchange load order. It is not possible for the algorithm to determine the correct order, because it can't determine which interchange these entities will actually be loaded in, because they can be loaded in from multiple interchanges. With the duplication of entities described, it leads to the following dependency graph, which shows dependencies between interchanges and the labels show which entities are causing the dependencies.

By removing these two entities from all interchanges except Standards, the dependency graph looks like the following, which generates a valid and usable loading order for most load scenarios: