Details

This section outlines general conventions that apply to the Snapp XSD as a whole, or to elements used throughout the XSD.

Required Elements

A minimally populated XML file that adheres to the Snapp Data Standard has very few required entities (e.g., Name, ContactInfo) and a few required elements within those required entities (e.g., FirstName, LastName, Email). The Context entity is also required and contains a few metadata elements (e.g., Created, CreatedBy, ApplicationLanguage).

An example of a minimally populated XML data file is shown below:

XML v3.0 Minimally Populated Data File

<?xml version="1.0" encoding="UTF-8"?>
<ScholarshipApplication xmlns="http://www.scholarsnapp.org/scholarshipapplication" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sds="http://www.scholarsnapp.org/scholarshipapplication" xsi:schemaLocation="http://www.scholarsnapp.org/scholarshipapplication Snapp-Data-Standard-v30c.xsd">
	<Context>
		<Created>2017-03-12T20:20:10.001Z</Created>
		<CreatedBy>ScholarSnapp.org</CreatedBy>
		<ApplicationLanguage>en-US</ApplicationLanguage>
	</Context>
	<Student>
		<Name>
			<FirstName>Testy</FirstName>
			<LastName>McTestface</LastName>
		</Name>
		<ContactInfo>
			<Email>testy.mctestface@example.com</Email>
		</ContactInfo>
	</Student>
</ScholarshipApplication>

We recommend implementers follow these guidelines:

Do not send files before FirstName, LastName, and Email are available in your application context.
Do not send files with whitespace or other placeholder text in required fields. Some implementers find it useful to save initial versions of the XML file with placeholder values (e.g., to allow an early version of the file to pass validation even if the required information isn't yet known). That's fine, but we recommend that you not exchange files with these values.
Do not send optional entities containing whitespace or placeholder values in their required elements. Omit the optional entity instead. For example, BirthPlace is an optional entity, but contains the required element StateOrProvince. If your application has not yet collected the StateOrProvince information at the time you send the XML data file, simply omit the whole BirthPlace entity.

Overall File Size and Attachment

The Snapp Data Standard XSD itself doesn't enforce an overall file size. This isn't a problem for the vast majority of data in the standard – but since the standard allows for mime-encoded attachments, the file size could theoretically grow to a point where it causes problems for data exchange. To avoid the situation where implementers must handle files of an arbitrarily large size, we recommend that data exchange implementers follow these guidelines:

Do not send Snapp XML Data Files exceeding 5mb, unless explicitly agreed upon with the recipient.
Do offer the option to receive data without attachments, e.g., through an API.
Do omit attachments by default, e.g., through an API.

The Scholar Snapp Central API adheres to these guidelines. We can receive bulk data exchanges containing larger files.

Honor Ye Olde Robustness Principle

Regarding the exchange of Snapp Data Files, we encourage implementers to follow the good advice:

Do be liberal in what you accept and conservative in what you send.
Do ensure Snapp XML Data Files validate against the intended XSD before sending.
Notwithstanding your commitment to the above, do be forgiving of what you receive, and handle error conditions gracefully.

In practice, we've found that different XML libraries return different results, so there's always a chance your validation will return a different result than a sender's validation.

CEEB Codes

The School and College entity conveys a CEEB code, which is an organization identifier maintained by The College Board. Snapp generally distinguishes between High Schools and Colleges in its data structures, but a good rule of thumb for evaluating data quality is as follows:

A 6-digit CEEB code is used to identify high schools
A 5-digit CEEB code is used to identify testing centers (e.g., places to take the SAT, PSAT, etc.)
A 4-digit CEEB code is used to identify colleges

School Entity and Homeschooling

The School entity conveys structured information about a student's school choices and school transcript, and includes structures for an NCES code and a CEEB code. We strongly recommend that implementers leverage those code values instead of solely relying on the free-form SchoolName text element. If you've ever done text matching to look up schools by name, you know why.

A few implementers have asked us how to address homeschooling (e.g., for Transcript information). The Snapp School entity contains a CEEB code, and the following CEEB definitions are useful:

970000 is the CEEB code for homeschooling
000004 is the CEEB code for an unlisted international school
000003 is the CEEB code for an unlisted domestic school

School Entity NCES Codes and IPEDS Codes

The School entity contains an NCESCode element. A few notes:

The NCESCode is a string value (as opposed to, say, an enumeration). The exact list of NCES codes varies depending on the data source and the age of the data source. By convention, implementers may disregard NCES code values not in their authoritative source.
The NCESCode is the Pre-K through 12th Grade school system name for the IPEDS code. By convention, implementers may supply an IPEDS code value in the NCESCode element to identify institutes of higher education.

Data Standard Documentation Contents