PREVIOUS VERSION
This site is the documentation for a Scholar Snapp Austin (v3.0), a previous version of the Scholar Snapp Technology Suite.
The Snapp solution is currently backward-compatible with v3.0, but all new development projects should leverage Scholar Snapp Technology Suite Berkeley (v4.0).
What's New in Snapp v3.0
- Ian Christopher (Deactivated)
Scholar Snapp v3.0 went through several updates for the 2017-2018 application cycle. Many updates and improvements were suggested by existing implementers. Some updates were made to accommodate changes in the real world (e.g., new SAT testing scoring). A few updates correct errors or typos in the standard.
The Snapp team heartily thanks all the implementers, technologists, and subject matter experts that provided input for Snapp v3.0.
We welcome and accept feedback any time. If you are a current or prospective implementer of the Snapp Data Standard or the Snapp Central API and would like to provide input or be included in the next RFC period, please send a note to Governance@scholarsnapp.org with your contact information.
Changes in v3.0
This section contains an overview of the changes in v3.0.
Discussed on this page:
Detail on each topic follows.
Element Changes and Additions
Ambiguity Removed from Required Elements (SSDS-1)
The v2.0 XSD specification has a logical ambiguity in many required elements: the specification allows required strings to be of zero length, meaning that the value can actually be null.
This issue tripped up field implementations (which expect "required" values to be non-null), including the Snapp UI itself (which was developed to require a non-zero-length string in "required" string fields).
Change Detail
The proposed v3.0 XSD will add a minLength=1
restriction to the ShortString
and LongString
types (lines 7 and 16 in the following snippet):
... <xs:simpleType name="ShortString"> <xs:annotation> <xs:documentation>String used for short text fields</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="LongString"> <xs:annotation> <xs:documentation>String used for long text fields, such as essays</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> ...
The ShortString and LongString types are used as a base class for most string values in the standard. This change will force all elements that are present to have a non-zero-length string as a value.
The following snippet illustrates the practical effect of the change in XML data files:
... <!-- Valid in v2.0, will not validate in v3.0 --> <sds:FirstName></sds:FirstName> ...
The example above will not validate in v3.0 because FirstName is present, but doesn't meet the minimum length requirement.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-1)
- See this change in GitHub (88e9a97)
Allow Multiple Races to be Indicated, Refine Enumeration Values (SSDS-2, SSDS-28)
The v2.0 Snapp Standard uses the same race list as the U.S. Census Bureau -- but unlike the census and the U.S. DoE reporting, the Snapp standard only allows a single selection for the Race enumeration.
Other refinements are also needed: the enumeration values for races are CamelCase with no space, which is unlike the rest of Snapp, and one item is incorrectly listed as "AsianOrOtherPacificIslander" but should simply read "Asian".
This change allows multiple races to be indicated, and cleans up item inconsistencies.
Change Detail
The proposed v3.0 XSD will add maxOccurs="unbounded"
to the existing RacesList, allowing multiple selections (line 2 in the following snippet):
... <xs:element name="Race" type="sds:RacesList" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Student's race</xs:documentation> </xs:annotation> </xs:element> ...
The following snippet illustrates the practical effect of the change in XML data files, including the change to the enumeration item value style:
... <!-- Not valid in v2.0, will validate in v3.0 --> <sds:Race>American Indian or Alaska Native</sds:Race> <sds:Race>White</sds:Race> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-2, SSDS-28)
- See these changes in GitHub (7182b87, 71ba077)
Add Values to the GovernmentPrograms Enumeration (SSDS-38)
Implementers that use participation in government programs to inform a need-based decision requested additional fields in Snapp. Several were added.
Change Detail
The updated GovernmentProgramList follows:
... <xs:simpleType name="GovernmentProgramList"> <xs:annotation> <xs:documentation>The list of government aid programs</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="FreeOrReducedSchoolLunch"> <xs:annotation> <xs:documentation>The National School Lunch Program (NSLP) from the U.S. Department of Agriculture</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="FoodStampsOrOtherNutritionalAssistance"> <xs:annotation> <xs:documentation>Food stamps, Electronic Benefit Transfer (EBT) program, or other financial support for nutrition</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="HealthInsuranceAssistance"> <xs:annotation> <xs:documentation>State or federal government insurance assistance including MediCal, CHIP, not including Medicaid which is a separate item</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="HousingAssistanceOrReducedCostHousing"> <xs:annotation> <xs:documentation>Housing assistance including HUD Section 8, public housing, and government-subsidized housing</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="LIHEAPOrOtherUtilityAssistance"> <xs:annotation> <xs:documentation>The Low Income Home Energy Assistance Program (LIHEAP) from the U.S. Department of Health and Human Services</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="Medicaid"> <xs:annotation> <xs:documentation>The Medicaid joint federal and state program</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="SocialSecurityDeathOrDisability"> <xs:annotation> <xs:documentation>Social Security benefits for dependents due to death or disability (SSDI), not including standard retirement</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="SpecialSupplementalNutritionWIC"> <xs:annotation> <xs:documentation>The Special Supplemental Nutrition Program for Women, Infants, and Children (WIC) from the U.S. Department of Agriculture</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="SupplementalSocialSecurity"> <xs:annotation> <xs:documentation>Supplemental Security Income (SSI) from the U.S. Social Security Administration</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="TemporaryAssistanceToNeedyFamilies"> <xs:annotation> <xs:documentation>The Temporary Assistance for Needy Families (TANF) program from the U.S. Department of Health and Human Services</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="OtherGovernmentProgram"> <xs:annotation> <xs:documentation>Indicates that the student participates in a government program of a type not specified in the Snapp model</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-38)
- See this change in GitHub (0b4c3d7)
Add Values to the Attached File Type List (SSDS-43)
The v2.0 Snapp Standard had a relatively brief list of file type attachments, many of which were general (e.g., "Picture"). In v3.0, several new types were added.
Change Detail
The updated AttachedFileTypeList follows:
... <xs:simpleType name="AttachedFileTypeList"> <xs:annotation> <xs:documentation>Content of the attached file, whether a transcript, a picture, etc.</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="Audio"/> <xs:enumeration value="College Board CSS PROFILE - Data"/> <xs:enumeration value="College Board CSS PROFILE - Printable"/> <xs:enumeration value="Degree Certificate"/> <xs:enumeration value="Diploma Certificate"/> <xs:enumeration value="FAFSA"/> <xs:enumeration value="Formal Student Portrait - Large"/> <xs:enumeration value="Formal Student Portrait - Small"/> <xs:enumeration value="Informal Picture of Student"/> <xs:enumeration value="Medical Document"/> <xs:enumeration value="Picture"/> <xs:enumeration value="Portfolio Document"/> <xs:enumeration value="Proof of Achievement"/> <xs:enumeration value="Proof of Employment"/> <xs:enumeration value="Recommendation/Reference Letter"/> <xs:enumeration value="School Acceptance Letter"/> <xs:enumeration value="Student Aid Report (SAR)"/> <xs:enumeration value="Transcript"/> <xs:enumeration value="USDoE MyStudentData File"/> <xs:enumeration value="Video"/> <xs:enumeration value="Other"/> </xs:restriction> </xs:simpleType> ...
For continuity, any existing general values such as Audio were left in the standard – but going forward, new file types should have well-defined standards, formats, or documented norms to define the file.
See the Attached Files Entity documentation for the specifications and usage guidelines for each enumeration value.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-43)
- See this change in GitHub (5cb5dba)
Add NCES CIP Codes to Snapp (SSDS-41)
Snapp contains information about an applicant's intended major or field of study. The NCES CIP code provides an expansive, standard taxonomy of codes that define fields of study. CIP code support was added to Snapp v3.0.
Change Detail
CIP code support was added to the Major complex type via a new MajorCIPCode element. Examples of CIP codes include 03.0201 (indicating Natural Resources Management and Policy) and 40.0805 (indicating an exciting career in Plasma and High-Temperature Physics). There are hundreds of codes, so rather than provide an enumeration the element is a string field. The code listing below shows the XSD definition in context:
... <xs:complexType name="Major"> <xs:annotation> <xs:documentation>The student's intended course of study</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="MajorName" type="sds:ShortString"> <xs:annotation> <xs:documentation>The student's intended area of study when in school</xs:documentation> </xs:annotation> </xs:element> <xs:element name="MajorCIPCode" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>The NCES CIP Code (i.e., the Classification of Instructional Programs) for the student's intended major (e.g., 09.0401 represents journalism, 40.0202 represents astrophysics)</xs:documentation> </xs:annotation> </xs:element> ... </xs:complexType> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-41)
- See this change in GitHub (9990a12)
Add counselor phone number to CollegeReadinessProgram complex type (SSDS-7)
Implementers using the College Readiness Program entity noted that it was missing a phone number for the Counselor. This change would add an optional counselor phone number to the complex type.
Change Detail
The CollegeReadinessProgram complex type contains simplified contact information (e.g., using a purpose-built first/last name vs. a Name element). In keeping with that idiom, we added a simple string value, illustrated on 12:
... <xs:complexType name="CollegeReadinessProgram"> <xs:annotation> <xs:documentation>The student's participation in a college readiness program</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="ProgramName" type="sds:CollegeReadinessProgramList"/> <xs:element name="ProgramOtherDesc" type="sds:ShortString" minOccurs="0"/> <xs:element name="CounselorFirstName" type="sds:ShortString" minOccurs="0"/> <xs:element name="CounselorLastName" type="sds:ShortString" minOccurs="0"/> <xs:element name="CounselorEmail" type="sds:ShortString" minOccurs="0"/> <xs:element name="CounselorPhoneNumber" type="sds:ShortString" minOccurs="0"/> <xs:element name="LengthOfParticipation" type="xs:duration" minOccurs="0"/> </xs:sequence> </xs:complexType> ...
The following snippet illustrates a use of the new counselor phone number option in XML data:
... <!-- Updated CRP with counselor phone number in v3.0 --> <sds:CollegeReadinessPrograms> <sds:ProgramName>AVID</sds:ProgramName> <sds:ProgramOtherDesc>Advancement Via Individual Determination</sds:ProgramOtherDesc> <sds:CounselorFirstName>Manuel</sds:CounselorFirstName> <sds:CounselorLastName>Diaz</sds:CounselorLastName> <sds:CounselorEmail>md@example.edu</sds:CounselorEmail> <sds:CounselorPhoneNumber>512-555-9876</sds:CounselorPhoneNumber> <sds:LengthOfParticipation>P2Y</sds:LengthOfParticipation> </sds:CollegeReadinessPrograms> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-7)
- See this change in GitHub (7182b87)
Structure the College Readiness Program Name (SSDS-5)
The Snapp Data Standard v2.0 used a free-form text field to capture the College Readiness Program name. However, implementation partners that use the CRP for eligibility require a structured list for the field to be useful. The v2.0 complex type already had a ProgramDescOther element which appears to be a holdover from an earlier draft in which the College Readiness Program name was an enumeration.
We used the Dell Scholars Program list as a starting point because it is fairly extensive and nationwide in the U.S., supplemented by desktop research.
Change Detail
We created a new CollegeReadinessProgramList enumeration. The new enumeration contains all entries from the Dell Scholars Program, plus a few others revealed from desktop research (e.g., NMSI). We added an "Other" value and a "None" value to cover applications where the student affirms that they have not participated in a college readiness program.
We changed the existing CollegeReadinessProgram.ProgramName from an sds:ShortString to sds:CollegeReadinessProgramList. The new CollegeReadinessProgramList enumeration follows:
... <xs:simpleType name="CollegeReadinessProgramList"> <xs:annotation> <xs:documentation>The list of common college readiness programs</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="Alliance"/> <xs:enumeration value="AP Strategies"/> <xs:enumeration value="ASPIRE"/> <xs:enumeration value="AVID"/> <xs:enumeration value="Bottom Line"/> <xs:enumeration value="Breakthrough Austin"/> <xs:enumeration value="College Forward"/> <xs:enumeration value="College Possible"/> <xs:enumeration value="College Track"/> <xs:enumeration value="Cristo Rey Network"/> <xs:enumeration value="Fulfillment Fund"/> <xs:enumeration value="GEAR UP"/> <xs:enumeration value="Genesys Works"/> <xs:enumeration value="Green Dot"/> <xs:enumeration value="IDEA Academy"/> <xs:enumeration value="KIPP"/> <xs:enumeration value="Let's Get Ready"/> <xs:enumeration value="Mastery Charter Schools"/> <xs:enumeration value="NMSI"/> <xs:enumeration value="Noble Network"/> <xs:enumeration value="One Goal"/> <xs:enumeration value="Philadelphia Futures"/> <xs:enumeration value="Uncommon Schools"/> <xs:enumeration value="Uplift Education"/> <xs:enumeration value="Upward Bound"/> <xs:enumeration value="Upward Bound Math-Science"/> <xs:enumeration value="YES Prep"/> <xs:enumeration value="None"/> <xs:enumeration value="Other"/> </xs:restriction> </xs:simpleType> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-5)
- See this change on GitHub (d2fef2e)
Organize and Add New Armed Services Elements (SSDS-40)
Implementers supporting scholarship programs for armed service members and their families requested a few additions to the Student entity and a set of characteristics for family members indicating their service history.
Change Detail
Two new entities were created: an Armed Services Student Characteristic and an Armed Services Relative Characteristic. These new elements collect and organize the properties relevant to military service.
All existing elements on the Student entity (e.g., the Veteran indicator, Child of POW/MIA indicator) were grouped in the Armed Services Student Characteristic. New elements for Student were added there (e.g., GI Bill Eligibility indicator). The XSD is shown below:
... <xs:complexType name="ArmedForcesStudentCharacteristics"> <xs:annotation> <xs:documentation>Characteristics related to armed forces programs, a student's armed forces service record, and other attributes common to armed forces scholarship applications</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Veteran" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the student is a military veteran</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VeteranDesc" type="sds:MilitaryBranchList" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>The branches of the military in which the student served</xs:documentation> </xs:annotation> </xs:element> <xs:element name="POW" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the student was ever a prisoner of war</xs:documentation> </xs:annotation> </xs:element> <xs:element name="POWDesc" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>War or conflict in which the student was a prisoner of war</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ChildOfPOWMIA" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the student is a child of a POW or MIA military service member</xs:documentation> </xs:annotation> </xs:element> <xs:element name="GIBillEligible" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the student is eligible for the G.I. Bill</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ActiveDuty" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the student is currently on active duty in the armed forces</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> ...
The added elements relevant to Relatives were similarly grouped into the new Armed Services Relative Characteristic entity. The XSD is shown below:
... <xs:complexType name="ArmedForcesRelativeCharacteristics"> <xs:annotation> <xs:documentation>Characteristics related to a relative's or spouse's armed forces service record, and other attributes common to armed forces scholarship applications</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Veteran" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the relative is a military veteran</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VeteranDesc" type="sds:MilitaryBranchList" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>The branches of the military in which the relative served</xs:documentation> </xs:annotation> </xs:element> <xs:element name="POWMIA" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the relative was ever a prisoner of war or listed as missing in action</xs:documentation> </xs:annotation> </xs:element> <xs:element name="POWMIADesc" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>War or conflict in which the relative was a prisoner of war or listed as missing in action</xs:documentation> </xs:annotation> </xs:element> <xs:element name="KIA" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the relative was a casualty classified as killed in action</xs:documentation> </xs:annotation> </xs:element> <xs:element name="KIADesc" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>War or conflict in which the relative was killed in action</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ActiveDuty" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation>Whether the relative is currently on active duty in the armed forces</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> ...
Incidentally, the element in v2.0 named "ChildofPOWMIA" was changed to "ChildOfPOWMIA" in v3.0 to match the naming conventions throughout the standard.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-40)
- See this change in GitHub (4988fdc)
Remove Unused Entities and Elements (SSDS-9)
Every data field included in the standard adds cost and complexity. This change would remove those elements that were infrequently used in the 2016-2017 application cycle.
Change Detail
An analysis was performed on over 100K XML data files. The following elements seldom (or never) contained actual data and so have been removed in v3.0:
- Student.Activities.YearOtherDesc
- Student.ClassRank.OtherRank
- Student.ClassRank.OtherRankDesc
- Student.Activities.OrganizationAddress (containing address elements)
- Student.StudentReferences.ReferenceAddress (containing address elements)
Note that some infrequently used elements are present for logical completeness, so were note removed. These include text fields that contain an explanation when an "Other" value is selected from an enumeration, standard-but-infrequent elements such as Address Line 2, the Salutation for the Student name type, and similar.
Other elements not removed are present to support key partners and future use cases. For example, several FAFSA-related fields are seldom used, but Snapp has future plans for these elements. ChildOfPOWMIA and other armed services values were also seldom used, but implementers of programs that support armed service members and their families asserted the value of those fields.
The Student.StudentReferences.YearsKnown, Student.GovernmentAidParticipation, and various College Readiness Program elements are seldom present in 2016-2017 data, but they're key eligibility criterion for current implementers and so were left in place.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-9)
- See this change in GitHub (75f18ea)
Organize and Improve FAFSA Elements (SSDS-19, SSDS-20, SSDS-29)
The FAFSA information in Snapp v2.0 has several opportunities for improvement.
- The Snapp Data Standard, by convention, groups similar elements into complex types in the XSD. For example, the "typical" address fields such as city, state, zip code, and so forth are grouped into an Address complex type. The FAFSA elements break this pattern with 8 elements directly related to the FAFSA form hanging directly off of the Student entity.
- The Snapp Data Standard v2.0 has several FAFSA-related elements, but does not collect the reported Adjusted Gross Income from the FAFSA form. Some need-based scholarship programs use this field to determine financial need/financial hardship for eligibility (or otherwise give some consideration).
Snapp contains several data fields related to, and defined by, the U.S.-centric FAFSA form. Even though the FAFSA values are expressed in USD, all the FAFSA-related elements include a CurrencyType. In addition, the Amount in v2.0 is a decimal, but the FAFSA form only includes whole dollar amounts.
This change reorganized and clarified the FAFSA elements.
Change Detail
The following changes were made to address the concerns with v2.0:
- Organize the FAFSA entities and elements into a new FAFSAInfo complex type.
- Add a new ParentsAdjustedGrossIncomeAmount element.
- Remove the CurrencyType from the FAFSA entities to reflect that the Amount values are, by definition, expressed in USD.
- Change the Amounts to xs:int to reflect the whole-dollar amounts in the FAFSA.
The changes were performed as a set, with the following result:
... <xs:complexType name="FAFSAInfo"> <xs:annotation> <xs:documentation>The Free Application for Federal Student Aid (FAFSA) information for a person</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="EFCAmount" type="xs:int" minOccurs="0"> <xs:annotation> <xs:documentation>The Expected Family Contribution (EFC) as reported on the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ParentsAdjustedGrossIncomeAmount" type="xs:int" minOccurs="0"> <xs:annotation> <xs:documentation>The student's parents' adjusted gross income (AGI) as reported on the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ParentsCashAmount" type="xs:int" minOccurs="0"> <xs:annotation> <xs:documentation>The student's parents' total current balance in cash, savings, and checking accounts as reported on the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ParentsNetWorthAmount" type="xs:int" minOccurs="0"> <xs:annotation> <xs:documentation>The net worth of student's parents' investments, including real estate (not including their home) as reported on the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ParentsBusinessInvestmentsAmount" type="xs:int" minOccurs="0"> <xs:annotation> <xs:documentation>The net worth of student's parents' current business and/or investment farms as reported on the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FilingStatus" type="sds:FAFSAStatusList" minOccurs="0"> <xs:annotation> <xs:documentation>The current filing status of the student's FAFSA form</xs:documentation> </xs:annotation> </xs:element> <xs:element name="StatusDesc" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>Free-form text description when the 'Other' FAFSA Status List option is indicated</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FilingYear" type="sds:ShortString" minOccurs="0"> <xs:annotation> <xs:documentation>The school year of the student's FAFSA filing in the format of two 4-digit years separated by a dash (e.g., 2016-2017)</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> ...
The following snippet illustrates the use of the reorganized and expanded FAFSA:
... <!-- Updated FAFSA data in v3.0 --> <FAFSA> <EFCAmount>13349</EFCAmount> <ParentsAdjustedGrossIncomeAmount>60000</ParentsAdjustedGrossIncomeAmount> <ParentsCashAmount>100000</ParentsCashAmount> <ParentsNetWorthAmount>500000</ParentsNetWorthAmount> <ParentsBusinessInvestmentsAmount>0</ParentsBusinessInvestmentsAmount> <FilingStatus>Filed</FilingStatus> <FilingYear>2017-2018</FilingYear> </FAFSA> ...
References
- View tickets in the Scholar Snapp Data Standard JIRA Site (SSDS-19, SSDS-20, SSDS-29)
- See this change on GitHub (d142ebf)
Add Optional Weighted GPA Indicator to GPAInfo (SSDS-21)
The Snapp Data Standard v2.0 has several GPA-related elements, but none indicating whether the reported GPA is weighted or unweighted. This change provides a means of indicating whether or not the reported GPA was weighted.
Change Detail
Version 3.0 adds a new optional xs:boolean
indicator to the GPAInfo type since all options could be weighted. Decided against adding annotations to existing GradingScaleList (e.g., "4.0 (Weighted)" and "Alphabetic (Weighted)") so as to not force a choice when sending from an application that doesn't specify.
Line 9 of the XML snippet below illustrates use in v3.0:
... <GPA> <SchoolName>Austin High School</SchoolName> <SchoolType>High school</SchoolType> <CumulativeGPA> <SchoolYear>High School Grade 10</SchoolYear> <GPA>3.2</GPA> <Scale>4.0</Scale> <Weighted>false</Weighted> </CumulativeGPA> </GPA> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-21)
- See this change on GitHub (95f9dfc)
Change StateOrProvince and Country to Enumeration (SSDS-11)
Snapp Data Standard v2.0 allowed open text values in StateOrProvince and Country. This made it easy for implementers to export data to Snapp, but is problematic for those importing files. For example, the U.S. could be any of the following: U.S., U.S.A., United States, US, U. S. A., U. S. of A., and so forth. Similarly, the great state of Texas could be TX, Texas, Tex., Tejas, or some other abbreviation that hasn't yet occurred to us.
This change modified the StateOrProvince and Country elements to enumerations.
The Scholar Snapp data model is primarily used in the U.S., and is not finely tuned for international addresses. For this reason, the Snapp Data Standard handles North American addresses and locations – but offers an "Other" option for both StateOrProvince and Country. This allows for some modest international support – and backward compatibility with the Snapp v2.0's more freewheeling model.
Change Detail
This results in the following changes:
- Adding a StateOrProvinceList enumeration containing postal codes for the U.S., U.S. outlying areas, U.S. armed forces addresses, Canadian provinces, and Mexican states.
- Adding a CountryList enumeration using the 2-letter ISO country code for the U.S., Canada, and Mexico.
- Replacing the StateOrProvince and Country in the Address entity with the enumerations.
- Adding StateOrProvinceOtherDesc to the Address entity to handle the "Other" option
- Adding CountryOtherDesc to the Address entity handle the "Other" option
- Swapping out free-form StateOrProvince and Country elements for the enumeration where they're used outside of Address (e.g., GraduationInfo.GraduationCountry), and adding the companion "Other" elements (e.g., GraduationInfo.GraduationCountryOtherDesc).
The changes to the XSD are fairly significant (see, e.g., the diff for bbc0ce0 in GitHub). However, the change to the actual data files is fairly easy to understand. See the following example for PermanentAddress:
... <!-- Acceptable in v2.0, will NOT validate in v3.0 --> <PermanentAddress> <AddressLine1>1234 Maple Street</AddressLine1> <City>Austin</City> <StateOrProvince>Tex.</StateOrProvince> <ZipOrPostalCode>78701</ZipOrPostalCode> <Country>U.S.A.</Country> </PermanentAddress> ... ... <!-- Will validate in v3.0 --> <PermanentAddress> <AddressLine1>1234 Maple Street</AddressLine1> <City>Austin</City> <StateOrProvince>TX</StateOrProvince> <ZipOrPostalCode>78701</ZipOrPostalCode> <Country>US</Country> </PermanentAddress> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-11)
- See this change on GitHub (bbc0ce0)
Use the School Entity (which contains NCES/CEEB Codes) vs. Free Text SchoolName Throughout (SSDS-15)
The Snapp Data Standard primarily uses an entity called School to signify a specific educational institution. The entity includes the option for an NCES code and/or a CEEB code in addition to a School Name, which allows unambiguous identification of a particular school. However, some entities, including the SimpleTranscript and GraduationInfo, allow for free-form entry of a school name.
This update changed all references to School Names to use the School entity.
Worth noting is that the SchoolName in the School entity is still a free-form text field with NCES code and CEEB code both optional. So, implementers that, for whatever reason, require free-form text can still use Snapp as flexibly as v2.0; this change simply supports (and implicitly encourages) implementers to be precise when indicating a school.
Change Detail
The change replaces all free-form text SchoolNames (and the one "CollegeName") with a School entity. This includes:
- Class.School
- ClassRank.School
- CollegeChoice.College
- Enrollment.School
- GPA.School
- GraduationInfo.GraduationSchool
The change also removed repetitive elements from entities where the change to school would have been duplicative. For example, the CollegeChoice had an NCESCode as well as a free-form CollegeName; that NCESCode was removed from CollegeChoice since it's included in the School entity.
The following snippet illustrates the change:
... <!-- New structure in v3.0, showing additional NCES and CEEB code opportunities --> <GPA> <School> <SchoolName>Austin High School</SchoolName> <NCESCode>480894000294</NCESCode> <CEEBCode>440320</CEEBCode> <SchoolType>High school</SchoolType> </School> <CumulativeGPA> <SchoolYear>High School Grade 9</SchoolYear> <GPA>3.2</GPA> <Scale>4.0</Scale> <Weighted>false</Weighted> </CumulativeGPA> </GPA> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-15)
- See this change on GitHub (b24fb23)
Change Underlying Type of CultureCodeList for Compatibility with Older Validation Libraries (SSDS-47)
Older XSD validation tools (e.g., xmllint in the libxml 2 suite) report an error in the Snapp XSD's CultureCodeList. This is incorrect. The XSD validates in, e.g., XML Spy and OxygenXML, and appears to be an obscure but known bug.
However, we found that some implementers, including the Snapp Central API, rely on libraries that contain the same bug. So, we want to modify the XSD in a way that's correct, but allows older validation tools to be used.
The problem appears to be in the underlying type of the CultureCodeList enumeration, which is declared using the xs:language type.
Change Detail
Simply changing the underlying type from xs:language to sds:ShortString appears to be a safe fix with zero impact on XML data files -- because the enumeration defines the allowable values, anyway.
The annotation in the XSD was incorrect, pointing to an unrelated RFC. The annotation was also clarified.
... <xs:simpleType name="CultureCodeList"> <xs:annotation> <xs:documentation>The list of language and culture codes (e.g., en-US represents English spoken in the U.S., fr-CA represents French spoken in Canada). Language part is ISO 639-1, country is ISO Alpha-2. Roughly aligned with xs:language.</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="en-US"/> <xs:enumeration value="en-CA"/> <xs:enumeration value="af-ZA"/> ... <xs:enumeration value="vi-VN"/> </xs:restriction> </xs:simpleType>
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-47)
- See this change on GitHub (2dde9c8)
Simple Changes to Enumerations (Value Lists)
This section contains relatively simple changes to existing enumeration value lists.
Support new SAT and PSAT Test Types (SSDS-3, SSDS-39)
The v2.0 Snapp Standard had a structured list of test types which did not account for the 2016 changes to the SAT or the 2015 changes to the PSAT. This change supports the latest College Board test types as of January 2017, and deprecates older versions of tests with similar scoring.
Change Detail
Scholar Snapp v3.0 XSD updated the values in the TestsList
enumeration.
This change also includes a minor tweak to deprecated or other old tests: v2.0 noted old test types as obsolete (e.g., SAT Verbal (Obsolete)
). The proposed v3.0 changes this to indicate a timeframe (e.g., SAT Verbal (pre-2005)
), which provides implementers with a more meaningful indication of what the type represents. The following snippet shows all SAT and PSAT values, with unchanged test types elided:
... <xs:simpleType name="TestsList"> <xs:annotation> <xs:documentation>The different tests that a person can take</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="SAT Total"/> <xs:enumeration value="SAT Evidence-Based Reading and Writing"/> <xs:enumeration value="SAT Math"/> <xs:enumeration value="SAT Essay Reading"/> <xs:enumeration value="SAT Essay Analysis"/> <xs:enumeration value="SAT Essay Writing"/> <xs:enumeration value="SAT Reading Test"/> <xs:enumeration value="SAT Writing and Language Test"/> <xs:enumeration value="SAT Math Test"/> <xs:enumeration value="SAT Analysis in History/Social Studies Cross-Test"/> <xs:enumeration value="SAT Analysis in Science Cross-Test"/> <xs:enumeration value="SAT Command of Evidence Subscore"/> <xs:enumeration value="SAT Words in Context Subscore"/> <xs:enumeration value="SAT Expression of Ideas Subscore"/> <xs:enumeration value="SAT Standard English Conventions Subscore"/> <xs:enumeration value="SAT Heart of Algebra Subscore"/> <xs:enumeration value="SAT Problem Solving and Data Analysis Subscore"/> <xs:enumeration value="SAT Passport to Advanced Math Subscore"/> <xs:enumeration value="SAT Critical Reading (pre-2016)"/> <xs:enumeration value="SAT Verbal (pre-2005)"/> <xs:enumeration value="SAT Math (pre-2016)"/> <xs:enumeration value="SAT Writing (pre-2016)"/> ...unchanged values elided <xs:enumeration value="PSAT Total"/> <xs:enumeration value="PSAT Evidence-Based Reading and Writing"/> <xs:enumeration value="PSAT Math"/> <xs:enumeration value="PSAT Reading Test"/> <xs:enumeration value="PSAT Writing and Language Test"/> <xs:enumeration value="PSAT Math Test"/> <xs:enumeration value="PSAT Analysis in History/Social Studies Cross-Test"/> <xs:enumeration value="PSAT Analysis in Science Cross-Test"/> <xs:enumeration value="PSAT Command of Evidence Subscore"/> <xs:enumeration value="PSAT Words in Context Subscore"/> <xs:enumeration value="PSAT Expression of Ideas Subscore"/> <xs:enumeration value="PSAT Standard English Conventions Subscore"/> <xs:enumeration value="PSAT Heart of Algebra Subscore"/> <xs:enumeration value="PSAT Problem Solving and Data Analysis Subscore"/> <xs:enumeration value="PSAT Passport to Advanced Math Subscore"/> <xs:enumeration value="PSAT Critical Reading (pre-2015)"/> <xs:enumeration value="PSAT Verbal (pre-2005)"/> <xs:enumeration value="PSAT Math (pre-2015)"/> <xs:enumeration value="PSAT Writing (pre-2015)"/> <xs:enumeration value="PSAT Selection Index"/> ...more unchanged values </xs:restriction> </xs:simpleType> ...
The following snippet illustrates a subset of the allowable SAT and PSAT values in XML data files:
... <!-- High-level SAT and PSAT in v3.0 --> <sds:TestScores> <sds:Test>SAT Total</sds:Test> <sds:Score>1350</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2017-01-10</sds:ScoreDate> </sds:TestScores> <sds:TestScores> <sds:Test>SAT Math</sds:Test> <sds:Score>600</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2017-01-10</sds:ScoreDate> </sds:TestScores> <sds:TestScores> <sds:Test>SAT Evidence-Based Reading and Writing</sds:Test> <sds:Score>750</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2017-01-10</sds:ScoreDate> </sds:TestScores> <sds:TestScores> <sds:Test>PSAT Total</sds:Test> <sds:Score>1300</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2016-01-11</sds:ScoreDate> </sds:TestScores> <sds:TestScores> <sds:Test>PSAT Math</sds:Test> <sds:Score>700</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2016-01-11</sds:ScoreDate> </sds:TestScores> <sds:TestScores> <sds:Test>PSAT Evidence-Based Reading and Writing</sds:Test> <sds:Score>600</sds:Score> <sds:ScoreType>Highest ever score</sds:ScoreType> <sds:ScoreDate>2016-01-11</sds:ScoreDate> </sds:TestScores> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-3, SSDS-39)
- See this change in GitHub (7182b87, 66d993d)
Update EssayTypeList Enumeration (SSDS-13)
Implementers of the v2.0 Snapp Data Standard noted that there were some reasonably common essay types not included in the enumeration of essay types. This change provides additional essay types via the EssayTypeList enumeration.
Change Detail
This change added 8 new essay types:
- Financial need or hardship
- Challenges foreseen with college
- Why student is applying for scholarship
- Challenging or questioning ideas
- Topic of student's choice
- Role model or influential person in student's life
- Book or other artwork influential in student's life
- Personal attribute or quality
In addition, it corrects one item to align with the style of other items:
- Community impact upon the student (removed leading "The")
The complete v3.0 enumeration is below.
... <xs:simpleType name="EssayTypeList"> <xs:annotation> <xs:documentation>The essay categories that are available</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="Affecting the lives of others"/> <xs:enumeration value="Athletic involvement, achievements, and impact on the student"/> <xs:enumeration value="Book or other artwork influential in student's life"/> <xs:enumeration value="Challenges foreseen with college"/> <xs:enumeration value="Challenging or questioning ideas"/> <xs:enumeration value="Community contribution"/> <xs:enumeration value="Community impact upon the student"/> <xs:enumeration value="Community leadership"/> <xs:enumeration value="Disciplinary or legal problems"/> <xs:enumeration value="Education plans beyond graduation"/> <xs:enumeration value="Explanation of student's college choices"/> <xs:enumeration value="Explanation of student's major choices"/> <xs:enumeration value="Failures and the resulting lessons learned"/> <xs:enumeration value="Family background or history"/> <xs:enumeration value="Favorite activity"/> <xs:enumeration value="Financial need or hardship"/> <xs:enumeration value="Home responsibilities"/> <xs:enumeration value="How college readiness programs helped the student"/> <xs:enumeration value="How ethnicity shaped the student"/> <xs:enumeration value="How the student challenged herself"/> <xs:enumeration value="Leadership experiences"/> <xs:enumeration value="Lifetime goals and objectives"/> <xs:enumeration value="Organizational leadership roles and outcomes"/> <xs:enumeration value="Overcoming adversity"/> <xs:enumeration value="Personal achievements, awards, and honors"/> <xs:enumeration value="Personal attribute or quality"/> <xs:enumeration value="Personal background or history"/> <xs:enumeration value="Post graduation and career goals"/> <xs:enumeration value="Problem or issue in the world student would like to address"/> <xs:enumeration value="Role model or influential person in student's life"/> <xs:enumeration value="Special circumstances affecting college finance"/> <xs:enumeration value="Special programs participation and outcomes"/> <xs:enumeration value="Topic of student's choice"/> <xs:enumeration value="Work responsibilities"/> <xs:enumeration value="Why student deserves the scholarship"/> <xs:enumeration value="Why student is applying for the scholarship"/> <xs:enumeration value="Other"/> </xs:restriction> </xs:simpleType> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-13)
- See this change on GitHub (546edab)
Expand ClassTypeList to indicate "General" and Pre-AP classes (SSDS-6, SSDS-36)
The v2.0 Snapp Standard contained a ClassTypeList that used in the Transcript to indicate special characteristics of a class (e.g., Honors, AP, IB, Dual enrollment).
Implementers suggested that a "Regular" entry would be useful for data exchange. This allows systems importing profiles to differentiate between classes that are "Regular" classes and classes that have no indication because the sending system simply doesn't collect class type information or didn't include that information in the profile.
We considered values such as "General" or "Regular" or "Standard" or similar.
Implementers also noted that a structured "Pre-AP" value would be useful.
Change Detail
Both CEDS and the Ed-Fi Data Standard use "General" to indicate regular classes, so we used that option for v3.0. We also added the missing "Pre-AP" value. The following code snippet shows the complete ClassTypeList with the added values on line 7 and 10:
... <xs:simpleType name="ClassTypeList"> <xs:annotation> <xs:documentation>The type of student courses</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="General"/> <xs:enumeration value="Senior"/> <xs:enumeration value="Honors"/> <xs:enumeration value="Pre-AP"/> <xs:enumeration value="AP"/> <xs:enumeration value="IB"/> <xs:enumeration value="Dual enrollment"/> <xs:enumeration value="Special education"/> <xs:enumeration value="Remedial"/> <xs:enumeration value="Other"/> </xs:restriction> </xs:simpleType> ...
The following snippet illustrates the use of the new General and Pre-AP options in XML data:
... <!-- The General value indicates a non-AP, non-IB, non-Remedial, plain old everyday class --> <sds:SimpleTranscript> <sds:ClassName>Calculus</sds:ClassName> <sds:Year>High School Grade 12</sds:Year> <sds:Status>In progress</sds:Status> <sds:Grade>B</sds:Grade> <sds:Scale>Alphabetic</sds:Scale> <sds:Type>General</sds:Type> <sds:SchoolName>Austin High School</sds:SchoolName> </sds:SimpleTranscript> ... <!-- The Pre-AP value in action --> <sds:SimpleTranscript> <sds:ClassName>Pre-AP Physical Science</sds:ClassName> <sds:Year>High School Grade 9</sds:Year> <sds:Status>Complete</sds:Status> <sds:Grade>A</sds:Grade> <sds:Scale>Alphabetic</sds:Scale> <sds:Type>Pre-AP</sds:Type> <sds:SchoolName>Austin High School</sds:SchoolName> </sds:SimpleTranscript>
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-6, SSDS-36)
- See this change in GitHub (9eb65cc, 879af0d)
Expand ScholarshipPurposeList to include 1-Year programs (SSDS-42)
Implementers noted that 1-Year Programs (e.g., for CTE scholarships) were not included as a program option. These are valid for many programs, including those serving armed services members and families, so we added a value to the scholarship purpose element.
Change Detail
Snapp v3.0 adds the missing value. The updated ScholarshipPurposeList follows:
... <xs:simpleType name="ScholarshipPurposeList"> <xs:annotation> <xs:documentation>The types of schools for which a student may use a scholarship</xs:documentation> </xs:annotation> <xs:restriction base="sds:ShortString"> <xs:enumeration value="High school"/> <xs:enumeration value="Certificate program"/> <xs:enumeration value="1-year program"/> <xs:enumeration value="2-year program"/> <xs:enumeration value="4-year program"/> <xs:enumeration value="Graduate program"/> <xs:enumeration value="Other"/> </xs:restriction> </xs:simpleType> ...
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-42)
- See this change in GitHub (9f6c8d4)
Non-Breaking & Cosmetic Changes
Improve inline annotations (SSDS-4, SSDS-27)
The v2.0 Snapp Standard had several annotations that are mercilessly terse. Others contain light spelling errors and typos. This change makes simple corrections, all of which are non-breaking.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-4, SSDS-27)
- See this change in GitHub (d17e656, 931f5e7)
Non-Breaking XSD Organization Improvements (SSDS-23, SSDS-24, SSDS-25)
The Snapp v2.0 XSD contained several opportunities for improvement to make the standard easier for developers to understand and use. These changes are non-breaking – meaning they have no impact on the XML data file, only the readability of the XSD itself.
Changes include:
- The Snapp v2.0 XSD had no obvious organizational scheme. It appears that type declarations are sometimes near where they're used, and other times at the end of the XSD.
- Enumeration type names usually, but not always, end in "List".
- Some enumerations have no obvious organization or sorting order.
These changes make organizational improvements to address the above.
Change Detail
The following changes made address the concerns with v2.0:
- Organize the XSD into complex type, simple type, and enumeration declarations. Add annotations as a header for each section.
- Rename all enumeration types to end in "List"
- Ensure enumeration item lists have some logical order, either by a natural sequence, alphabetically, an increasing scale, or similar.
References
Data Standard Documentation Contents