The Scholar Snapp solution was updated for the 2018-2019 application cycle. The data model changes in the Snapp Profile (i.e., the applicant data exchanged by the Snapp Central API) were relatively light compared with previous updates. Most updates to the Snapp Profile data model were suggested by existing implementers. 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.

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.

Overview

The information that follows describes changes in the latest version of Scholar Snapp. 

The changes include:

Detail on each change follows.

Changes to the Snapp Data Standard and API

This section describes changes to the Snapp Data Standard, which defines the data payload representing an applicant's data.

Refine Gender, Gender Detail, and Orientation (SSDS-56)

Snapp previously contained three elements related to the notion of gender and gender identity. Based on community and partner feedback, we’ve updated the way in which we represent the notion of biological sex and gender identity.

Snapp has included gender identity information (i.e., information beyond a binary M/F choice) since its first version in 2008. In v3.0, we added a distinction between biological sex and gender identity. For Berkeley, we have implemented several improvements.

In Snapp 4.0, we have elected to keep certain things the same. 

• Gender information is optional. The Snapp Profile treats gender information as optional. Accordingly, applicants are not required to enter gender or gender identity information when using the online Snapp Application form. The application's online help makes this clear. If gender identity data is present (e.g., if received from a partner requiring the information), students can remove that information from their profile.
• There is a simple, nullable gender field indicating the applicant's current biological sex. Most of our current scholarship providers use a binary Male / Female choice – and for many, the value is required. Similarly, many partners have indicated that they're addressing gender identity by providing options equivalent to "Male," "Female," and "Choose not to respond." So, we will continue to have the simple M/F/unspecified value to remain compatible with those scholarship providers.
• We provide support for the notion of gender identity with an approach that's both sensitive and practical. A common piece of advice when asking how to convey gender identity information is "Don't ask." However, given our history providing support and interest from current partners, we do intend to provide support in the Berkeley version of Snapp. In addition, some scholarship programs are for the benefit of individuals with a specific gender identity, and our nascent scholarship search feature can use this information to provide applicants with scholarship options for which they qualify.

Change Detail

In Snapp 4.0, we have

• Gender information is optional. The Snapp Profile treats gender information as optional. Accordingly, applicants are not required to enter gender or gender identity information when using the online Snapp Application form. The application's online help makes this clear. If gender identity data is present (e.g., if received from a partner requiring the information), students can remove that information from their profile.
• There is a simple, nullable gender field indicating the applicant's current biological sex. Most of our current scholarship providers use a binary Male / Female choice – and for many, the value is required. Similarly, many partners have indicated that they're addressing gender identity by providing options equivalent to "Male," "Female," and "Choose not to respond." So, we will continue to have the simple M/F/unspecified value to remain compatible with those scholarship providers.
• We provide support for the notion of gender identity with an approach that's both sensitive and practical. A common piece of advice when asking how to convey gender identity information is "Don't ask." However, given our history providing support and interest from current partners, we do intend to provide support in the Berkeley version of Snapp. In addition, some scholarship programs are for the benefit of individuals with a specific gender identity, and our nascent scholarship search feature can use this information to provide applicants with scholarship options for which they qualify.

Change Detail

In Snapp 4.0, we have made the following changes:

• The creation of a new Gender Identity element that combines the current Gender Detail and Orientation elements. Version 3.0 of Snapp separates biological gender values such as transsexual and transitioning from sexual orientation values such as gay and lesbian. Since those values are more typically found grouped into a single notion of identity, we have combined the values into a single "Gender Identity" element.
• The creation of a new, expansive Gender Identity enumeration. To date, we haven't found an authoritative standard that is reasonably inclusive of the values found represented by the LBGTQIA acronym and our partners. We've created an amalgam of values from various studies, sources such as the GLAAD Media Reference Guide, and the values in use by partners. 
• Support an explicit Prefer Not to Answer option. Rather than simply leave the Identity field optional, some applications and surveys offer a way for the applicant to indicate they would prefer not to answer. We are accommodating that – in addition to leaving the element optional.
• Use a "Prefer to Self-Identify (Other)" value for Gender Identity. Many surveys and applications asking about gender identity support a free-form text field. To support these partners, we have added a "Prefer to Self-Identify (Other)" value in the Gender Identity enumeration with an accompanying 100-character text field. Generally speaking,  "Prefer to Self-Identify" or similar inclusive language is used to indicate a free-form entry for this value. But, we include "Other" in the value text as a hint for technologists and analysts doing data mapping. This element is analogous to Facebook's "Custom" gender option. 

The following XSD snippet shows the list definition and enumeration items.

made the following changes:

• The creation of a new Gender Identity element that combines the current Gender Detail and Orientation elements. Version 3.0 of Snapp separates biological gender values such as transsexual and transitioning from sexual orientation values such as gay and lesbian. Since those values are more typically found grouped into a single notion of identity, we have combined the values into a single "Gender Identity" element.
• The creation of a new, expansive Gender Identity enumeration. To date, we haven't found an authoritative standard that is reasonably inclusive of the values found represented by the LBGTQIA acronym and our partners. We've created an amalgam of values from various studies, sources such as the GLAAD Media Reference Guide, and the values in use by partners. 
• Support an explicit Prefer Not to Answer option. Rather than simply leave the Identity field optional, some applications and surveys offer a way for the applicant to indicate they would prefer not to answer. We are accommodating that – in addition to leaving the element optional.
• Use a "Prefer to Self-Identify (Other)" value for Gender Identity. Many surveys and applications asking about gender identity support a free-form text field. To support these partners, we have added a "Prefer to Self-Identify (Other)" value in the Gender Identity enumeration with an accompanying 100-character text field. Generally speaking,  "Prefer to Self-Identify" or similar inclusive language is used to indicate a free-form entry for this value. But, we include "Other" in the value text as a hint for technologists and analysts doing data mapping. This element is analogous to Facebook's "Custom" gender option. 

The following XSD snippet shows the list definition and enumeration items.

	...
	<xs:simpleType name="GenderIdentityList">
		<xs:annotation>
			<xs:documentation>The gender identity of a person</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Asexual"/>
			<xs:enumeration value="Bisexual"/>
			<xs:enumeration value="Gay"/>
			<xs:enumeration value="Genderfluid"/>
			<xs:enumeration value="Genderqueer"/>
			<xs:enumeration value="Intersex"/>
			<xs:enumeration value="Lesbian"/>
			<xs:enumeration value="Non-binary"/>
			<xs:enumeration value="Nonconforming"/>
			<xs:enumeration value="Pansexual"/>
			<xs:enumeration value="AsexualQuestioning"/>
			<xs:enumeration value="BisexualStraight"/>
			<xs:enumeration value="GayStraight Ally"/>
			<xs:enumeration value="GenderfluidTransgender, Female to Male"/>
			<xs:enumeration value="GenderqueerTransgender, Male to Female"/>
			<xs:enumeration value="IntersexTransitioning, Female to Male"/>
			<xs:enumeration value="LesbianTransitioning, Male to Female"/>
			<xs:enumeration value="Non-binaryPrefer Not to Answer"/>
			<xs:enumeration value="Nonconforming"/>
			<xs:enumeration value="PansexualPrefer to Self-Identify (Other)"/>
			<xs:enumeration value="Questioning"/>
			<xs:enumeration value="Straight"/>
			<xs:enumeration value="Straight Ally"/>
			<xs:enumeration value="Transgender, Female to Male"/>
			<xs:enumeration value="Transgender, Male to Female"/>
			<xs:enumeration value="Transitioning, Female to Male"/>
			<xs:enumeration value="Transitioning, Male to Female"/>
			<xs:enumeration value="Prefer Not to Answer"/>
			<xs:enumeration value="Prefer to Self-Identify (Other)"/>
		</xs:restriction>
	</xs:simpleType>
	...

Refine Class Type List Enumeration (SSDS-34)

The ClassTypeList (e.g., AP, IB, General) was established using the values from the Dell Scholars Program and other initial implementers as a guide. This improvement pegs the list to an external standard or norm.

• CEDS, for example, has a Course Level Characteristic enumeration. This has a number of values such as "Completion of requirement, but no units of value awarded" and "Career and technical education general course" that conceptually map to expected values, but from a style perspective are rather long.
• The Ed-Fi Data Standard has a conceptually similar enumeration but with more concise values than CEDS. The Ed-Fi Data Standard values "feel" more in-line with the rest of the Snapp idiom.

At this point, the Ed-Fi Data Standard looks like the external standard closest to the values relevant to Snapp partners.

Change Detail

The base enumeration in the Ed-Fi Data Standard appears closest to the intent and existing values in Snapp. We now align to that list of values, in the following manner:

• No existing Snapp values are be modified (for backward compatibility).
• Existing Snapp values with a clear mapping to a different value in the Ed-Fi Data Standard are unchanged in Snapp (for backward compatibility).
• We have added values we find in the Ed-Fi Data Standard for which a value does not already exist. Additions will follow the existing Snapp patterns for capitalization and abbreviation.
• We have alphabetized the value list. 

The following XSD snippet shows the definition of the Class Type List in v4.0:

</xs:restriction>
	</xs:simpleType>
	...

Refine Class Type List Enumeration (SSDS-34)

The ClassTypeList (e.g., AP, IB, General) was established using the values from the Dell Scholars Program and other initial implementers as a guide. This improvement pegs the list to an external standard or norm.

• CEDS, for example, has a Course Level Characteristic enumeration. This has a number of values such as "Completion of requirement, but no units of value awarded" and "Career and technical education general course" that conceptually map to expected values, but from a style perspective are rather long.
• The Ed-Fi Data Standard has a conceptually similar enumeration but with more concise values than CEDS. The Ed-Fi Data Standard values "feel" more in-line with the rest of the Snapp idiom.

At this point, the Ed-Fi Data Standard looks like the external standard closest to the values relevant to Snapp partners.

Change Detail

The base enumeration in the Ed-Fi Data Standard appears closest to the intent and existing values in Snapp. We now align to that list of values, in the following manner:

• No existing Snapp values are be modified (for backward compatibility).
• Existing Snapp values with a clear mapping to a different value in the Ed-Fi Data Standard are unchanged in Snapp (for backward compatibility).
• We have added values we find in the Ed-Fi Data Standard for which a value does not already exist. Additions will follow the existing Snapp patterns for capitalization and abbreviation.
• We have alphabetized the value list. 

The following XSD snippet shows the definition of the Class Type List in v4.0:

	...
	<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="Advanced"/> <!-- New -->
			<xs:enumeration value="AP"/>
			<xs:enumeration value="Career and technical education"/> <!-- New, equivalent to 'CTE' -->
			<xs:enumeration value="College-level"/> <!-- New -->
			<xs:enumeration value="Core subject"/> <!-- New -->
			<xs:enumeration value="Correspondence course"/> <!-- New -->
			<xs:enumeration value="Distance learning"/> <!-- New -->
			<xs:enumeration value="Dual enrollment"/>
			<xs:enumeration value="English language learner"/> <!-- New, equivalent to 'ELL' -->
			<xs:enumeration value="General"/> <!-- Existing, equivalent to 'Basic' -->
			<xs:enumeration value="Gifted and talented"/> <!-- New, equivalent to 'GTE' -->
			<xs:enumeration value="High school equivalent"/> <!-- New -->
			<xs:enumeration value="Honors"/>
			<xs:enumeration value="IB"/>
			<xs:enumeration value="Magnet"/> <!-- New -->
			<xs:enumeration value="Pre-AP"/>
			<xs:enumeration value="Pre-IB"/> <!-- New -->
			<xs:enumeration value="Remedial"/>
			<xs:enumeration value="Senior"/>
			<xs:enumeration value="Special education"/> <!-- Existing, maps to 'Students with disabilities' -->
			<xs:enumeration value="Untracked"/> <!-- New -->
			<xs:enumeration value="Other"/>
		</xs:restriction>
	</xs:simpleType>
	...

Add DACA Indication and Additional Citizenship Status Options (SSDS-59)

Some scholarship programs directly serve DREAMers and other individuals who have current or pending DACA status. The previous version of Snapp has citizenship values that plausibly apply, but no explicit indication of DACA status. This change adds a DACA indication to Snapp.

Other additions to Citizenship status should be considered. For example, the federal Student Aid Report (SAR) has statuses not represented in Snapp, but likely meaningful to scholarship programs. 

Change Detail

We have added two DACA-specific values to the Citizenship Status List enumeration in Snapp:

• Current DACA Status
• Pending DACA Application

In addition, we have added the following SAR values to the same Citizenship Status List enumeration:

• Conditional Permanent Resident
• FAFSA-Eligible Non-Citizen
• Asylum-Seeker or Asylee
• Cuban or Haitian Entrant
• Humanitarian Parolee

Existing enumeration items from Snapp v3.0 will remain unchanged.

The following XSD snippet shows the definition of the Citizenship Status List in v4.0:

	...
	<xs:simpleType name="CitizenshipStatusList">
		<xs:annotation>
			<xs:documentation>The list of possible citizenship statuses</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Asylum-Seeker or Asylee"/> <!-- New -->
			<xs:enumeration value="Conditional Permanent Resident"/> <!-- New -->
			<xs:enumeration value="Cuban or Haitian Entrant"/> <!-- New -->
			<xs:enumeration value="Current DACA Status"/> <!-- New -->
			<xs:enumeration value="FAFSA-Eligible Non-Citizen"/> <!-- New -->
			<xs:enumeration value="Humanitarian Parolee"/> <!-- New -->
			<xs:enumeration value="Non-U.S. Citizen"/>
			<xs:enumeration value="Pending DACA Application"/> <!-- New -->
			<xs:enumeration value="Refugee or Protected Person"/>
			<xs:enumeration value="Resident Alien or Permanent Resident"/>
			<xs:enumeration value="U.S. Citizen"/>
		</xs:restriction>
	</xs:simpleType>
	...

Clarify and Refine Armed Services Criteria (SSDS-61)

During internal development and testing of a scholarship search feature, the Snapp technical team discovered a few ambiguities in the Armed Forces Student Characteristics entity.

Ambiguity issues include:

• The service status (e.g., active duty, reserve duty, veteran) are independent of each other, and also not clearly tied to a service branch. This means there's not an unambiguous way indicate an applicant is a veteran of one service branch and currently on active duty in another.
• Reserve statuses are baked in to the service branch (e.g., "Army Reserve" is a distinct "service" from "Army"), which is not really accurate.

There are also a few housekeeping issues that have been fixed:

• The service branch is indicated by an element called "VeteranDesc", which is not correct since the element is used generically to indicate the service branch.
• The list of statuses has no way to indicate that an individual is retired.

Change Detail

We have made the following changes to the Armed Forces Student Characteristics entity:

• Refactoring existing Armed Forces Student Characteristics elements that represent service and status into a single entity indicating Service History. Elements affected by this reorganization include VeteranDesc (a 0-n enumeration), Veteran (a Boolean status), and Active Duty (another Boolean status).
• The history now contains a branch (e.g., Army, Navy), and a service status associated with that particular branch (e.g., Veteran, Active Duty). To maintain compatibility with existing semantics, we will implement the service status as optional.
• Include the service status values of Retired and Reserve Duty.
• The various reserve branches (e.g., Army Reserve, Coast Guard Reserve) have been removed, and instead Reserve Duty service status now indicates that state of being.

• The "VeteranDesc" element has been renamed "MilitaryBranch."

The changes are applied both to the applicant entity and the analogous entity on Relative.

The following XML snippet shows the v3.0 and analogous v4.0 record for an applicant:

	<!-- OLD applicant armed forces elements in v3.0 -->
	...
	<ArmedForcesCharacteristics>
		<Veteran>true</Veteran>
		<VeteranDesc>Army</VeteranDesc>
		<POW>false</POW>
		<ChildOfPOWMIA>false</ChildOfPOWMIA>
		<GIBillEligible>false</GIBillEligible>
		<ActiveDuty>false</ActiveDuty>
	</ArmedForcesCharacteristics>
	...

	<!-- NEW applicant armed forces elements in v4.0 -->
	...
	<ArmedForcesCharacteristics>
		<StudentServiceRecord>
			<MilitaryBranch>Army</MilitaryBranch>
			<ArmedServiceStatus>Veteran</ArmedServiceStatus>
			<WarOrConflict>First Gulf War</WarOrConflict>
		</StudentServiceRecord>
		<ChildOfPOWMIA>false</ChildOfPOWMIA> <!-- Unchanged -->
		<GIBillEligible>false</GIBillEligible> <!-- Unchanged -->
	</ArmedForcesCharacteristics>
	...

The following XML snippet shows the v3.0 active duty flag and analogous v4.0 active duty indication for an applicant:

	<!-- OLD active duty flag in v3.0 -->
	...
	<ArmedForcesCharacteristics>
		...
		<ActiveDuty>true</ActiveDuty>
	</ArmedForcesCharacteristics>
	...

	<!-- NEW active duty indication in v4.0; for backward compatibility, branch not required (though recommended)  -->
	...
	<ArmedForcesCharacteristics>
		<StudentServiceRecord>
			<ArmedServiceStatus>Active Duty</ArmedServiceStatus>
		</StudentServiceRecord>
		...
	</ArmedForcesCharacteristics>
	...

Add Indicator for Current Grade Level (SSDS-65)

The previous v3.0 Snapp Profile had many fields related to current educational attainment such as the Education Level element, the Graduation Info entity, and so forth. However, there was no indicator for Current Grade Level, which is a fairly common and significant qualifying component for scholarship programs. This change addresses that gap.

Change Detail

This change adds a Current Grade Level enumeration to the Snapp Profile, and a new element was added to the Education Level complex type to hold the enumeration value. Additionally, the current Education Level element in the complex type was changed from required to optional.

The following XSD snippet shows the definition of the Current Grade Level List in v4.0:

	...
	<xs:simpleType name="CurrentGradeLevelList">
		<xs:annotation>
			<xs:documentation>The list of current grade levels for an applicant. Tracks to eligibility, so contains grade levels (e.g., High School Senior, College Freshman) plus a few options that indicate a situation or status (e.g., 5th Year College Undergraduate, On Academic Break).</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="High School Freshman"/>
			<xs:enumeration value="High School Sophomore"/>
			<xs:enumeration value="High School Junior"/>
			<xs:enumeration value="High School Senior"/>
			<xs:enumeration value="Community College Freshman"/>
			<xs:enumeration value="Community College Freshman - Attended College Previously"/>
			<xs:enumeration value="Community College Sophomore"/>
			<xs:enumeration value="College Freshman"/>
			<xs:enumeration value="College Freshman - Attended College Previously"/>
			<xs:enumeration value="College Sophomore"/>
			<xs:enumeration value="College Junior"/>
			<xs:enumeration value="College Senior"/>
			<xs:enumeration value="5th Year College Undergraduate"/>
			<xs:enumeration value="Nth Year College Undergraduate"/>
			<xs:enumeration value="Graduate Student"/>
			<xs:enumeration value="Doctoral Candidate"/>
			<xs:enumeration value="Postgraduate Medical School"/>
			<xs:enumeration value="Postgraduate Law School"/>
			<xs:enumeration value="Not Enrolled"/>
			<xs:enumeration value="On Academic Break"/>
		</xs:restriction>
	</xs:simpleType>
	...

These values are aligned with the Snapp Program Information data model. Some of the oddly specific entries (e.g., 5th Year College Undergraduate) are based on program eligibility requirements we've seen in the field.

Update List of College Readiness Programs (SSDS-66)

The previous v3.0 Snapp Profile already has a list of College Readiness Programs. This change simply updates the list of programs in the standard.

Change Detail:

We reviewed lists used by our partners (e.g., the Dell Scholars Program) for updates and changes. We found a few updates and otherwise left existing program names in the enumeration unchanged.

The following XML snippet shows the College Readiness Program list in v4.0.

	...
	<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"/> <!-- New -->
			<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="KIPP Through College (KTC)"/> <!-- New -->
			<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>
	...

Changes In Progress or Coming Soon

This section describes changes to the Snapp solution that are expected sometime in the 2018-2019 scholarship application cycle.

Support for Snapp Data Standard v4.0 with Backward Compatibility

The Snapp Data Standard XML payload is updated for the 2018-2019 scholarship cycle. The Snapp Central API is updated to serve XML that conforms with the new standard, but maintains backward compatibility with the Snapp Data Standard v2.0 (from the 2016-2017 cycle) and v3.0 (the current version developed for the 2017-2018 cycle).

Change Detail

Pulling a new Snapp Data Standard is enabled via an HTTP GET with a querystring key version and the value 4. 

Retrieving a v4.0 Snapp Profile from Snapp Central:

HTTP Method: GET
Request URL: https://www.scholarsnapp.org/api/profile/snappfile?version=4
Header:
  Authorization Bearer [bearer token value]

Sending a v4.0 Snapp Profile to Snapp Central:

HTTP Method: POST
Request URL: https://www.scholarsnapp.org/api/profile/snappfile?version=4
Headers: 
  Authorization Bearer [bearer token value]
    Content-Type application/xml

Current implementers will note that calls to the API are the same as the current version other than the version value.

In order to support backward compatibility and a seamless upgrade path for current implementers, sending version=3 will continue to emit and accept profiles conformant with Snapp Data Standard v3.0, and sending version=2 (or omitting the version key from the querystring) will continue to emit and accept profiles conformant with Snapp Data Standard v2.0.

Add Scholarship Application Eligibility Criteria (SSDS-58)

Most scholarships have one or more criteria defining who is eligible to receive the scholarship. Common criteria include current age, grades, test scores, affiliations (e.g., with a company or organization), and so forth. In Snapp v3.0, some of this information is not present (e.g., affiliation with a church or religious organization) and other information can be indirectly derived if a student has completed a thorough profile.

This change adds simple, direct representations of common scholarship eligibility criteria to Snapp.

Change Detail

Rather than "bolt on" eligibility criteria to the existing Snapp Profile Data Standard, we now have a new Snapp Eligibility Data Standard. This standard will convey a compact representation of common criteria – most of which could be derived from the more complex, data-rich entities in Snapp.

The criteria – including any identifying information – is optional, so sending systems can provide only the information of use to the receiving system.

Criteria for inclusion are:

• Academic eligibility (GPA, test scores, etc.)
• Activity eligibility (sports, hobbies, etc.)
• Affiliation eligibility (membership in clubs, churches, employee of organizations, relative of employee of organizations, etc.)
• Armed services eligibility (service branch, service status such as active duty or reservist or veteran, etc.)
• College readiness program participation (AVID, College Forward, KIPP, et al.)
• College preference
• Condition (mental or physical conditions, not necessarily disabilities)
• Current profession
• Current school
• Financial eligibility (FAFSA EFC, etc.)
• Location
• Field of study
• Grade level (current grade, such as graduating high school senior, second year of college, etc.)
• Interest criteria (general interest – distinct from activity, in that someone "interested" in golf is different from someone who plays golf)
• Situation (various life situations such as caregiver, homeless, teen parent; includes not necessarily adverse situations such as living abroad)

Create Optional Streamlined Registration Path (SSDS-62) (New 4/4)

Most users first visit Snapp by reference from another site. On the first visit, users are (of course) required to register and set up an account.

However, this means that registration is usually an interruption to a program flow or user experience in another context. So, we (and end-user applicants) want that interruption to be as low-effort and fast as possible. For that reason, we ask the minimum possible information on registration (e-mail, password).

Some partners have encouraged us to ask for a little more information on our registration (primarily, e.g., First Name & Last Name). The idea is that any given account will have at least a thin core of data beyond just an e-mail address. This creates an obvious tension between adding more information and keeping the process streamlined.

Change Detail

One approach is to offer a streamlined registration path, whereby a partner can securely send (e.g., via HTTP POST) information to Snapp that can pre-populate the registration form with basic, non-invasive core data our partner "knows" about an applicant that Snapp does not.

For example, most partner application flows offer Snapp after the partner application already knows the applicant's e-mail address, first name, and last name. If that information was securely sent to Snapp, it would smooth even the existing registration process while ensuring that the applicant has a useful core of data at registration time.

Requirements include:

• The streamlined registration is optional. In the near-term, this will ensure that existing implementations are unaffected. However, we believe it will always be optional both to keep the bar for implementation to a minimum, and because many partners will have policies that prevent data exchange of any kind — even well-intentioned data exchange — without explicit user consent, and may not want the UI/UX overhead to get what they feel is informed consent.
• We will offer a small range of core data around e-mail, name, and basic contact info – and not anything that an applicant might find alarming (e.g., demographic information, financial information). 

Improve "No Profile Found" Response

There is a not-uncommon program flow in which a user is sent to Snapp from a partner site to retrieve their application information, but the user doesn't already have a profile. The program flow allows the user to set up an account, but when the API returns to the referring site, it sends a message in the body of the response noting that a profile wasn't found instead of the XML payload expected when a user already has a Snapp account.

Implementers have noted this adds complexity to their client code since they might receive either an XML payload or a literal text string as a response.

Change Detail

We will now send an XML file conformant to the Snapp Data Standard, even for newly registered users.

The minimum valid Snapp profile contains three pieces of user-collected data: e-mail address, first name, and last name. The Snapp registration currently requests only an e-mail address from new users.

Implementers have suggested adding first name and last name to the initial Snapp registration, or simply sending placeholder values. We are adding placeholder values, simply to keep the initial setup as fast as possible, as the new user flow is already an interruption to the flow of our partners' systems.

Provide fully RESTful API with a JSON Representation of the Snapp Profile

The primary data payload for Scholar Snapp is XML, betraying its roots as a downloadable file developed in the 2000s. While the file is wrapped in a modern, somewhat RESTful JSON API, implementers have suggested that the option to interact with a fully RESTful API with a JSON representation of the Snapp Profile file would be desirable.

Change Detail

We are now adding RESTful endpoints and JSON support to the existing API, but will continue to support the current XML-based payload via the existing endpoints. The OAuth flow will remain the same across the endpoints, and the JSON representation will be harmonized with the XML representation of an applicant's Snapp Profile.

We are implementing the following for differentiating the content type:

• Snapp Central will honor a new Accept header for the GET method:
  • A GET with an Accept application/xml will return XML
  • A GET with an Accept application/json will return JSON
  • For convenience, a new querystring type parameter will be supported for GETs (e.g., type=json, and type=xml); if both the Accept header and the type parameter are provided, the type parameter will be honored
  • For backward-compatibility, a GET with nothing specified will return XML
• Snapp Central already has a Content-Type header for the POST method:
  • A POST with Content-Type application/xml will continue to expect XML
  • A POST with Content-Type application/json will expect JSON

Auto-Enter Information from MyStudentData Files

Many Scholarship Applications request data from an applicant's FAFSA. Accordingly, the Snapp v3.0 XSD conveys several frequently used FAFSA fields, like Expected Family Contribution, Adjusted Gross Income, and so forth. The U.S. DoE has an initiative that allows students to create a downloadable data file containing FAFSA data.

See this link, for example, about the program:
https://studentaid.ed.gov/sa/resources/mystudentdata-download

See this link, for example, about the data format:
https://ifap.ed.gov/eannouncements/attachments/FAFSAMyStudentDataDownloadRecordLayout.pdf

The MyStudentData file is one of the file types in the Snapp enumeration. Users and implementers have noted that if the Snapp Central API supports the upload of a machine-readable format, it would make sense to read the file and complete any relevant Snapp elements not already present.

Change Detail

We now support the automated entry of data from the MyStudentData download file.

The 2017-2018 MyStudentData CSV file contains the following fields that map to elements in Snapp, or provide information that would enable us to add data to an applicant's Snapp Profile:

To be clear, we haven't seen very many of the CSV files in use by applicants. However, we have worked with individuals to download the file, and it's reasonably easy and quick (if one knows where to look). We will therefore invest in some communication and documentation to let students know about this potentially useful time-saving approach to adding data to their profile.

For the initial version, we will add information only if it's not already present (vs. update or synch information). However, we will also accept information any time so an applicant can realize the benefit at any point in the applicant lifecycle.

Support an Optional, Persistent, Revocable Profile Access Token

The current token (i.e., the OAuth bearer token) that client systems use to access a Snapp Profile is short-lived, effectively meaning that end-user applicants must supply Snapp with login credentials every time they grant access to a client system to read or write their data. This provides a security benefit to applicants. It also ensures that Snapp users are aware that their data has been accessed.

However, this level of control comes at a cost to convenience, which some users view as a disincentive to using Snapp. It also imposes some limitations on client systems: for example, the short-lived nature of the token effectively removes a store-and-forward queue on the client side, and makes transient errors difficult to recover from.

Allowing an optional, persistent token provides secure support for:

• More frequent exchange between client systems and Snapp. Some clients have understandably chosen to limit the exchanges with Snapp because of the detriment to their users' current experience. This change would improve the experience such that more frequent exchanges are not clunky. But client systems could also, for example, poll for and pull new information from Snapp at the start of a user's session and push new information to Snapp at the end of a user's session. This would be possible today, but a frustrating experience.
• Asynchronous exchange. Client systems could initiate a data exchange without interfering with their end-user's experience. Client systems today do not have the option for background synchronization, queuing, or recovery from a longish but transient error.

This change supports an opt-in, longer-lived, revokable access token, allowing end-users to grant ongoing permissions for a particular client system to update their Snapp Profile data.

Change Detail

Applicants may now choose their own balance between security and convenience, and retain control over the permissions they grant to client applications. The features generally follow those principles:

• The persistent token is opt-in for the applicant, meaning that users can continue to require credentials every time their profile data is accessed. Client systems will be passed a timeout value which will indicate the lifespan of a token.
• The persistent token is opt-in for client systems as well. In other words, client systems can continue to work as they do today. Initially, this is a necessary convenience so as not to impact current implementations – but, at this point, we envision continuing to support this option. The change does imply some user experience, user interface, and core development work on the client side, so we want to let client system owners choose if and when to do that work.
• The persistent token will be revokable through the Snapp user interface. We will encourage client systems to offer a way to purge persistent tokens as well.
• We will continue to track access to Snapp Profile data, and expect to provide a means for applicants to view a history of access to their profile.

 Math-Science"/>
			<xs:enumeration value="YES Prep"/>
			<xs:enumeration value="None"/>
			<xs:enumeration value="Other"/>
		</xs:restriction>
	</xs:simpleType>
	...

Changes In Progress or Coming Soon

This section describes changes to the Snapp solution that are expected sometime in the 2018-2019 scholarship application cycle.

Add Scholarship Application Eligibility Criteria (SSDS-58)

Most scholarships have one or more criteria defining who is eligible to receive the scholarship. Common criteria include current age, grades, test scores, affiliations (e.g., with a company or organization), and so forth. In Snapp v3.0, some of this information is not present (e.g., affiliation with a church or religious organization) and other information can be indirectly derived if a student has completed a thorough profile.

This change adds simple, direct representations of common scholarship eligibility criteria to Snapp.

Change Detail

Rather than "bolt on" eligibility criteria to the existing Snapp Profile Data Standard, we now have a new Snapp Eligibility Data Standard. This standard will convey a compact representation of common criteria – most of which could be derived from the more complex, data-rich entities in Snapp.

The criteria – including any identifying information – is optional, so sending systems can provide only the information of use to the receiving system.

Criteria for inclusion are:

• Academic eligibility (GPA, test scores, etc.)
• Activity eligibility (sports, hobbies, etc.)
• Affiliation eligibility (membership in clubs, churches, employee of organizations, relative of employee of organizations, etc.)
• Armed services eligibility (service branch, service status such as active duty or reservist or veteran, etc.)
• College readiness program participation (AVID, College Forward, KIPP, et al.)
• College preference
• Condition (mental or physical conditions, not necessarily disabilities)
• Current profession
• Current school
• Financial eligibility (FAFSA EFC, etc.)
• Location
• Field of study
• Grade level (current grade, such as graduating high school senior, second year of college, etc.)
• Interest criteria (general interest – distinct from activity, in that someone "interested" in golf is different from someone who plays golf)
• Situation (various life situations such as caregiver, homeless, teen parent; includes not necessarily adverse situations such as living abroad)

Changes Considered but Not Implemented

This section contains changes considered but not implemented in v4.0 based on feedback and further research.

Merge or Better Document Current Enrollments and Graduation Info (SSDS-44)

In Snapp v3.0 and prior, the Student.CurrentEnrollments element contains information about a student's present school, expected graduation date, etc., while the Student.GraduationInfo essentially contains past enrollment with a few additional details about the outcome (such as GPA, actual graduation date, etc.).

These are semantically distinct concepts, but the similarity between the two data structures can be confusing, especially because many applicants will have "current" enrollments that become graduation events during the course of a Scholarship application cycle.

This improvement provides a solution that combines the two without losing the distinction between events we expect to happen in the future and events that have already happened.

Change Detail

For the Berkeley (v4.0) generation of Snapp, we address this issue via improved documentation, and leave the Snapp Profile definitions of the Current Enrollment and Graduation Info entities as it is in v3.0.

We are using this nontechnical approach because we believe having a distinct historical entity (i.e., conveying data that will always be true, presuming data is correct) is useful when separate from a current status (i.e., conveying data that's expected to change).

Reinforcing the do-nothing option is that a drafting exercise resulted in an inelegant entity when combined. For example, a combined entity must make distinctions between expected graduation date and actual graduation date, attempted degree and awarded degree, and similar issues.

Documentation improvements are made:

• In annotations (e.g., in the Snapp Data Standard XSD)
• In online documentation for the relevant elements