Uploaded image for project: 'Ed-Fi Data Standard'
  1. Ed-Fi Data Standard
  2. DATASTD-1041

Issues related to SchoolYearType - field usage and implementation

    XMLWordPrintable

Details

    • Story
    • Resolution: Done
    • Major
    • Data Standard v2.1
    • None
    • None
    • None

    Description

      Summary of outcomes for Data Standard 2.1

      • Problem Addressed: Current enumerations provided in SchoolYear type are too restrictive.
      • High-level Reasoning: The current SchoolYear type enumerations only run through 2029-2030. Students enrolling in preschool in 2017 may have graduation plans for graduation dates after 2030.
      • Changes Made: Added school years 2030-2031 through 2049-2050 to SchoolYear type

      Original ticket description follows:

      Opening a ticket to capture issues related to SchoolyearType.

      In the data standard it is a simple type, with an enumeration for school years covering the period from 1996 - 2030. The enumerations are school year ranges - i.e. "1996 -1997", "1997-1998", ...., "2029-2030"

      Field Use Issues

      Reported by Certica (RMcD): While mapping data from a SIS we came across graduation plans that had been created for preschoolers for the 2031 schoolyear which is outside of the bounds for the Schoolyear enumeration. This is an XML mapping and it causes the files to fail XSD validation. Even with an API call it will currently fail as the SchoolYearTypes are loaded as if they were types (from SQL generated off of the XSD enumeration) into the ODS via SQL during the database creation. There are workarounds that might work, like inserting additional rows into the SchoolYearType table for each implementation but would result in XML files that might load but fail XSD validation.

      Implementation Issues
      The ODS database implementation is a "one-off" that introduces a surrogate key (SchoolYear), that is the first part of the enumeration, and aSchoolYearDescription column that contains the enumeration.

      There is special purpose logic in various places to deal with this:

      • MetaEd special cases this to create the target ODS schema
      • ODS/API codegen special cases this to surface the data as a Type (but the JSON payload is different to all type) - where pattern-based approaches would like to treat it as a resource (see ODS-1154)
      • The ODS/API v3.0 codegen - based on an internal semantic mode

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              chris.moffatt Chris Moffatt
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Salesforce