Versions Compared
Version | Old Version 9 | New Version Current |
---|---|---|
Changes made by | ||
Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
The Snapp v3.0 RFC for 2017-2018 is closed.
Thank you to everyone who participated.
Release & Download Notes
This page contains the download and release notes for Scholar Snapp v3.0b, a beta draft released on March 31, 2017.
Panel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Download a ZIP archive containing the Snapp Data Standard v3.0b and a sample XML data file: |
What's in v3.0b?
This section outlines the updates and additions as of the draft Snapp v3.0b RFC XSD. Although the changes are technically valid, the Snapp team was still soliciting input as of this release – so the final form may be different, and we may back out changes prior to release if implementers advise us to do so.
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):
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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):
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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)
Support new SAT and PSAT Test Types (SSDS-3)
The v2.0 Snapp Standard has 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
The proposed v3.0 XSD will update 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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 Reading Essay"/> <xs:enumeration value="SAT Analysis Essay"/> <xs:enumeration value="SAT Writing Essay"/> <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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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)
- See this change in GitHub (7182b87)
Improve inline annotations (SSDS-4)
The v2.0 Snapp Standard has several annotations that are mercilessly terse. Others contain light spelling errors and typos. This proposed change makes simple corrections, all of which are non-breaking.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-4)
- See this change in GitHub (Work In Progress)
Expand ClassTypeList to indicate "General" classes (SSDS-6)
The v2.0 Snapp Standard contains a ClassTypeList that used in the Transcript to indicate special characteristics of a class (e.g., Honors, AP, IB, Dual enrollment).
Implementers have suggested that a "Regular" entry would be useful for data exchange. This would allow 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.
Change Detail
Both CEDS and the Ed-Fi Data Standard use "General" for this purpose, so we propose that option for v3.0. The following code snippet shows the complete ClassTypeList with the added value on line 7:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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="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 option in XML data:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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> ... |
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-6)
- See this change in GitHub (9eb65cc)
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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:ShortString"/> <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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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)
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 the latest draft:
- Student.Activities.YearOtherDesc
- Student.ClassRank.OtherRank
- Student.ClassRank.OtherRankDesc
- Student.GenderDetail
- Student.POW
- Student.POWDesc
- Student.ChildofPOWMIA
- 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 recommended for removal 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.
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 reorganizes and clarifies the FAFSA elements.
Change Detail
The following changes are recommended 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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)
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 recommended 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.
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
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 would provide some means of indicating whether or not the reported GPA was weighted.
Change Detail
Recommend adding 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
Consider Structuring the College Readiness Program Name (SSDS-5)
The Snapp Data Standard v2.0 uses 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 current complex type already has a ProgramDescOther element which appears to be a holdover from an earlier draft in which the College Readiness Program name was an enumeration.
We recommend using 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
Change StateOrProvince and Country to Enumeration (SSDS-11)
Snapp currently allows open text values in StateOrProvince and Country. This makes 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 even occurred to us.
This change would modify the StateOfProvince 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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, simply allow for free-form entry of a school name.
This proposed change would change all references to School Names to 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:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
... <!-- 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)
Non-Breaking XSD Organization Improvements (SSDS-23, SSDS-24, SSDS-25)
The Snapp v2.0 XSD contained several obvious opportunities for improvement to make the standard easier for developers to understand and use. Many of the changes recommended are non-breaking – meaning they have no impact on the XML data file, only the readability of the XSD itself.
Opportunities include:
- The Snapp v2.0 XSD has 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.
These recommended changes make several organizational improvements.
Change Detail
The following changes are recommended to 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.