Versions Compared
| Version | Old Version 16 | New Version 17 |
|---|---|---|
| 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.
In advance of the release, the Snapp team held a request for comments period, during which input and improvements were solicited from current and prospective implementers.
The RFC period is closed, but we welcome 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, please send a note to Governance@scholarsnapp.org with your contact information.
Changes in v3.0c
This section contains an overview of the proposed changes for the next version of the Scholar Snapp Data Standard. Some proposed changes have been drafted as part of v3.0a RFC, while other proposals are listed below for discussion and comment.
Discussed on this page:
| Table of Contents | ||||
|---|---|---|---|---|
|
Detail on each topic follows.
Proposed Changes in Current Draft
| Info |
|---|
Many of these changes were modeled in the v3.0b draft. See the Release & Download page for that draft of the XSD and a companion sample XML data file. |
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
Support new SAT and PSAT Test Types (SSDS-3, SSDS-39)
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 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:
| 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, SSDS-39)
- See this change in GitHub (7182b87, 66d993d)
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:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
Improve inline annotations (SSDS-4, SSDS-27)
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, SSDS-27)
- See this change in GitHub (d17e656, 931f5e7)
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:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
Expand ScholarshipPurposeList to include 1-Year programs (SSDS-42)
Implementers noted that 1-Year Programs (e.g., for CTE scholarships) were not included in the standard.
Change Detail
Snapp v3.0 adds the missing value. The updated ScholarshipPurposeList follows:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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)
Expand ClassTypeList to indicate "General" and Pre-AP classes (SSDS-6, SSDS-36)
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.
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:
| 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="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:
| 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> ... <!-- 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)
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)
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:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
... <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 the latest draft:
- 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 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. 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 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 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:
| 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.
References
- View tickets in the Scholar Snapp Data Standard JIRA Site (SSDS-23, SSDS-24, SSDS-25)
- See this change on GitHub (75f18ea)
Additional Changes Proposed, But Not Included in XSD
This section contains changes that are not yet in the draft data standard but are under consideration for v3.0. Presuming community agreement, the items in this section will be drafted in v3.0b of the XSD.
| Info |
|---|
Note that some items below will not be implemented without active community support, and others may not be implemented in the final v3.0 if there are technical or logistical limitations preventing the Snapp team from doing an awesome job. |
Specify Limits to Attachment File Sizes and Overall File Size (Best Practice)
RFC Status: Recommended, Open For Review and Comment
This would primarily affect the API, and will have at least an annotation/documentation impact on the XSD.
The Snapp Data Standard currently allows for MIME Base-64 attachments, but doesn't specify a file size limit. This has practical problems in API data exchange and implementation. This change would specify a maximum size for individual files and an overall size limit for the XML Data File.
The Snapp Central API currently does not transfer attachments by default. We expect that to continue as the norm.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-12)
Specify Norms for Common Attachments Like Student Portraits (Implementer Suggestion)
RFC Status: Open For Review and Comment
The Snapp Data Standard currently supports attachments and allows users to specify what the file represents. Implementers have suggested that Snapp provide standards and/or guidance for certain common types of attachments. For example, many scholarship applications request a portrait of a certain pixel dimension and similar.
This makes conceptual sense, but the Snapp team doesn't have a sense for the norms. Our recommendation for Snapp Data Standard v3.0 is to address this issue in documentation as non-normative guidelines for implementers, and revisit this issue based on feedback from this application cycle.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-14)
Evaluate Additional Support for Home Schooling (Implementer Suggestion)
RFC Status: Open for Review and Comment
The Snapp Data Standard v2.0 only contains light support for home schooling. This has been raised as a potential issue by implementers (e.g., because NCES code lists do not appear to have an option for homeschooling). The SchoolType enumeration has a "Home school" value, so it is currently possible to make the selection explicit.
This change would create additional support for home schooling in the standard (e.g., by specifying a placeholder NCES code and specific School Name value in the School Entity to indicate home schooling).
With SSDS-15, Snapp adds a School entity which contains CEEB code everywhere a school name is solicited. CEEB defines 970000 as the homeschooling option, so for now we're advising that implementers use that code, by convention, wherever home schooling is indicated.
We'll continue to solicit input on this front from providers, and will re-open in the 2018-2019 cycle.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-16)
Evaluate Additional Support for Home Responsibilities (Implementer Suggestion)
RFC Status: Open for Review and Comment
The Snapp Data Standard v2.0 contains minimal support for indicating home responsibilities, but it forms a major part of a few implementers' selection criteria. Consider options for adding additional, structured support.
A lightweight approach might be as simple as adding values to the existing ActivityTypeList (which contains values such as "Athletics" and "Hobby" in addition to a general "Home and family responsibilities" item). Alternately, a new, optional 0-n type might be indicated.
We haven't found an excellent model or example for Home Responsibilities, so for 2017 we aren't currently planning any structural changes to the XSD, rather we'll offer guidance in the Snapp Data Handbook and evaluate usage.
We'll continue to solicit input on this front from providers, and will re-open in the 2018-2019 cycle.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-17)
Changes NOT Recommended for v3.0
This section includes changes that were considered for v3.0, but are not recommended. A brief explanation is included with each entry.
Acknowledge Snapp is U.S.-Centric, Remove Half-Baked International Support (Governance Committee Suggestion)
RFC Status: Not Recommended for v3.0.
Action: Revisit in 2017-2018 Application Cycle
Original Notes:
Snapp can, theoretically, be used internationally, but in its current state it makes many U.S.-centric assumptions. In addition to not supporting certain international address formats, the standard has many elements for FAFSA (a distinctly U.S.-based concept), reliance on NCES codes (another U.S.-based concept), and similar.
This proposed change would acknowledge that Snapp implementers are U.S.-based, and make simplifying assumptions. For example:
- Remove CurrencyType
- Change StateOrProvince to enumeration
- Change Country to enumeration
We will also consider changes like removing ApplicationLanguage from Context and similar.
References
- View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-10)