The NSPA Scholarship Program Data Standard specification is operational in a few solutions, but the data exchange standard itself is still considered a draft. This section outlines the changes in v1.0d.

The NSPA and Dell Foundation teams thank all the NSPA Members, implementers, technologists, and subject matter experts who provided input.

Overview

The information that follows describes changes in the latest version of the NSPA Scholarship Program Data Standard.

The changes include:

Detail on each change follows.

Changes to the Data Model

This section describes changes to the data model, which defines the data payload representing a scholarship program.

Add a Program Category Indicator (SSDS-102/SPDS-39)

Programs often have characteristics that indicate high-level categorizations, such as “for first-generation students” or “for families of servicemembers.” These characteristics can typically be inferred from eligibility criteria or other properties of a program record — but there’s no convenient, universal method to indicate a broad category.

The value is useful as a high-level filter both to prospective applicants searching a list of programs and client systems receiving a set of program data records.

Change Detail

For Scholarship Exchange v1.0d, we’ve created a new Program Categories element. The value is optional, and may have up to four entries (i.e., the cardinality is 0..4).

Program Categories are implemented as a short string, with values defined by reference to an NSPA list. The list includes values such as:

• Academic

• Armed Service Family Member

• Armed Servicemember

• Contest

• First-Generation Student

• Professional Certification

• Transfer Student

• Other

…and more. The list will be finalized with the v1.0d release.

An example usage showing an academic scholarship for first-generation students is shown in the JSON snippet below:

Usage Detail

• The Program Category indicator is not intended to indicate everything about a program, just a few select, high-level categorizations. Generally speaking, data administrators will restrict indicators to the most significant one or two on any given program, up to a maximum of four categories.

• The Program Category indicator is often inferable from eligibility criteria or other properties of a given program. Note that this new element is not intended to replace those other properties, which typically convey additional detail.

• Not every data provider will find it useful to maintain this element since it can be considered duplicative of other elements. Where common sense dictates, those receiving data may make inferences about categories not present. For example, a program with eligibility criteria indicating that an applicant must be a child of an active duty army servicemember can be safely assumed to be categorizable as a program for armed service family members — even if the category “Armed Service Family Member” is not present.

• Generally speaking, the “Other” element should be infrequently used. Exchange data entry teams will consult program leads before adding an “Other” value.

• The Program Category element is conceptually close to the “Is Merit Based” and “Is Need Based” elements on the program. These may be merged in a future release, but for now are separate — and should not be added as “Other” Program Category criteria.

Add a New Associated Organization and Organization Type List (SSDS-110/SPDS-33, SSDS-94/SPDS-32)

The current Program Info standard allows for a single, primary organization to be associated with any given program. In practice, there are often several secondary, but important, organizations associated with a program, such as the organization funding the program, the community foundation that lists and administers the program, and so forth.

This change proposes the addition of an optional list of additional associated organizations, with indicators for the type of organization, the nature of the association (i.e., the role or roles an organization plays in relation to a program), and other elements.

Change Detail

For Scholarship Exchange v1.0d, we’ve added a new Additional Associated Organizations element.

• The entity is optional, and can list up to 4 additional organizations. We chose a reasonable upper limit because (a) there are only a few logical types of organization, and (b) each organization entity may contain a logo file, which could introduce file bloating if left unbounded.

• The entity allows for both a primary organization type (which is a singular value) and an organization role (which can be multiple).

• As noted, the entity allows for each listed organization to contain an associated logo file. The primary use case is for those programs that require attendance at a single, specific institution or graduation from a single, specific school. In listing use cases where the end user is a student searching for scholarship options, it may be useful to display a school or institution logo — which would allow for instant recognition that the program may have some applicability to the user. The school or institution logo may be displayed instead of or in addition to the primary logo, depending on the listing system’s user interface design.

Properties include:

• Organization Name.

• Organization Reference ID. In the NSPA Exchange implementation, this will be an internal NSPA Member ID for the organization, if available.

• Organization Type. The primary type of organization. Options currently include:

  • College or University

  • Community Foundation

  • High School

  • Hosting Service

  • Private Foundation

  • Trade or Technical School

• Organization Role. The role the organization plays in relation to the program. Options currently include:

  • Application Hosting Service Provider

  • Eligibility - Alumnus Requirement

  • Eligibility - Enrollment Requirement

  • Listing Service

  • Program Administrator

  • Program Funder

• Logo File. A Base 64-encoded image file.

• Logo File Name. A file name for the image file.

The following XSD snippet shows the definition with annotations:

Usage Detail

• Certain organization roles (such as when a college is listed because applicants must attend the specific institution) obviously have a relationship to the Eligibility Criteria. However, we do not intend for implementers to use these additional organizations as an additional eligibility criteria — rather, the data is provided for informational and display purposes.

• In the current generation of the NSPA Exchange, the element may be sparsely populated. The data maintenance team will likely focus on populating those records for which we have a specific display or functionality use case. The initial uses include:

  • Displaying a logo for a college, university, or school that applicants must attend to qualify for the award.

  • Displaying a logo for a high school or other institution from which applicants must be a graduate.

  • Relating Program Records to NSPA Member IDs to facilitate reporting and data lookup in the internal NSPA systems.

Create Flexible Code List Pattern & Replace Evolving Enumerations (SSDS-103/SPDS-19)

The current Program Info standard represents code lists/fixed vocabularies as classic enumerations. This provides welcome certainty in how to represent a fixed value. In unstructured lists, one sees various forms of the same information, such as "NMSI" or "National Math and Science Initiative" or "National Math and Science Initiative (NMSI)" in the same listing, so the controlled vocabulary provides assurance that values with the same definition have a single representation.

Changes to enumerations are considered breaking changes for implementers. (Or, at least those who perform schema validation or rely on enumerations for fixed lists in their applications.) However, in practice, there are several lists that need to evolve more rapidly than our annual major update lifecycle will allow.

Lists such as the eligibility criteria coding for Activities, College Readiness Programs, Interests, Demographics, and Miscellaneous change rapidly for a variety of reasons. Sometimes there are real-world changes such as a new College Readiness Program starting up, a new sport (Spikeball!? Whaaat?), or attitudes toward demographic categorizations such as gender identity. Other vocabulary items require change because new scholarships are found or created that have a particular requirement.

This change proposes the development of a flexible code list/vocabulary: one that has a fixed structure and a clear list of "known" values, but that may change during the life of a single generation of the standard.

Change Detail

For Scholarship Exchange v1.0d, we’ve changed several lists from enumerations to strings. The following enumerations have been removed:

1. ActivityList

2. AffiliationEntityList

3. CollegeReadinessProgramList

4. ConditionList

5. DemographicEligibilityCriteriaList

6. InterestCriteriaList

7. MiscellaneousCriteriaList

8. ProfessionList

9. SituationList

10. SchoolType (new in this version)

Where possible, a list’s reference will be to an existing, external standard (similar to how the school IDs are aligned with the CEEB and NCES codes by reference, or how country lists refer to the ISO-3166 2-letter country code).

Where no appropriate existing code list/vocabulary is found, the Exchange will publish and maintain its own standard. These Exchange standards will allow additive changes and deprecations within a single year/major version release. The lists may deprecate but will not remove or change existing values during a single year/major version release. This will allow an unambiguous set of “known” standard values, while allowing for rapid change during a single generation of the standard. A draft example for the Activity Code List is here.

We’ve replaced referenced enumerations such as the Activity Eligibility Criteria with a string. An example XML data snippet is shown below. Note that since the base type of enumerations in the Scholarship Exchange standard is also a string, the data file will appear largely unchanged from previous versions.

Add Address and School Type Info to Schools (SSDS-124/SPDS-14) (New 1/13)

The current Scholarship Exchange data model has multiple eligibility criteria related to schools or colleges, e.g., for college attendance and current school attendance. This latest version of the model adds a school relationship to indicate an alumnus requirement.

The current standard allows only for a name and NCES or CEEB code to identify a school. The two codes can, generally, uniquely identify a school and all its properties. However, use cases are arising in practice where reliance on a lookup is not desirable.

For example, the lookup source may not have a record for a school, which makes it desirable to include other identifying data (such as city and state) manually for later resolution. Also, in practice, performing analysis on a large set of scholarships can require thousands of lookups to the school data source — which can be alleviated by storing location and school type info with the Program Information record.

Change Detail

Added a School entity to hold the school name and school type, which itself contains a new Address entity to store the usual address elements.

The following entities use the new School entity:

• College Attendance Criteria (existing, but renamed in this version)

• Current School Criteria (existing)

• Graduation Status Criteria (existing, but school information added in this version)

Also added a School Type element. The school type is defined by the NSPA School Type value list — and currently contains only High School and College.

While this is a simple change conceptually, the restructuring is a fairly significant change to the data model. The following example data file illustrates the before-and-after view using XML data file snippets:

Usage Detail

• It’s expected that many data exchange and storage scenarios will sparsely populate the Address entity. For example, some may find it useful only if no unique NCES or CEEB code is present.

  • The NSPA Exchange intends to populate the address data, but offer a data exchange option to omit the Address information.

Add Minimum and Maximum Age Eligibility Criteria (SSDS-116/SPDS-10) (New 1/10)

The current Scholarship Exchange data model does not have a means of conveying Age criteria. This was a deliberate omission in earlier versions: Practically speaking, every program has a minimum limit and most have a practical, if unstated, maximum. But, for eligibility purposes, the majority of programs use “Current Grade Level” or “Degree Status” as a proxy for age.

However, as the Exchange database grows, we are encountering more programs with an explicit age requirement. For example, some programs are for the benefit of older learners returning to the workforce. Others serve students in multiple high school grades and state a minimum age criterion.

Change Detail

Added a new, optional, Age Criteria entity, with a Minimum Age Requirement and a Maximum Age Requirement.

• The minimum and maximum ages are expressed in integers (i.e., whole years).

• The years are inclusive. So, a minimum age requirement of 17 means 17-and-older.

Usage Detail

• The age entity should only be populated if age is both significant and explicitly stated as a criteria by the program.

• The age requirement is not intended to convey a “terms of service” or legal age limit. Every program has practical age limits, both stated and unstated, which are rarely useful data points for prospective applicants. Rather, most programs have requirements around current grade level or graduation status that serve the same purpose.

The following JSON snippet shows an example of a program targeted at people 35 or older.

Add Program Coding Support to Distinguish Eligibility Preferences from Eligibility Requirements (SSDS-99/SPDS-30)

The current Scholarship Exchange data model only allows for the mandatory eligibility requirements. However, many programs state “preferences” in addition to the mandatory eligibility requirements. These are stated by program providers as phrases like “Preference is given to female applicants” or “Preference will be given to applicants with a 3.5 or greater GPA” and similar.

Occasionally, the stated preferences repeat or refine the mandatory eligibility requirements. For example, some programs provide a mandatory minimum GPA, but state a preference for a higher minimum GPA.

Change Detail

Added a new, optional Preference Criteria entity.

• The new Preference Criteria entity, by design, mirrors the structure of the Eligibility Criteria. Technically, the schema uses the same definition for both.

• The same type of criteria may be present in both the Preference Criteria and the Eligibility Criteria (e.g., the example where a minimum GPA requirement is lower than the preferred minimum GPA).

An illustrative JSON data snippet is shown below:

The Eligibility Criteria are mandatory. Preference Criteria (starting on line 22) indicate that the program will give preference to applicants who intend to pursue a career in Accounting, but others may apply.

Data Model Design Note

We debated whether to add an IsRequired or IsPreference flag to the existing Eligibility Criteria as opposed to creating a whole new element with distinct semantics. On a balance, we believe that the distinct entity is simpler and easier to understand, and, in practice, easier to ignore if a receiving system does not consider the coding for preferences.

The current design does make data entry validation and data stewardship more important, because it’s easier to mistakenly add a duplicate criterion to both the Eligibility Criteria and Preference Criteria. However, we feel the gain in understandability and usage by those receiving the data outweigh those concerns. If we’re wrong, we’ll consider refactoring in future updates.

Usage Detail

• It’s not an error to have the same Criteria Type appear in both the Preference Criteria and Eligibility Criteria. In the oft-noted example above, there may be a Minimum GPA stated in both the required and preference criteria. Obviously, there should not be semantically identical or conflicting listings in both entities, so one wouldn’t expect to see the same Minimum GPA in both — or a lower Minimum GPA in the Preference Criteria than the mandatory Eligibility Criteria.

• By convention, if conflicting or confusing data are present in the Preference Criteria and Eligibility Criteria entities, implementers should honor the values in the Eligibility Criteria and ignore the Preference Criteria.

Add an Element for Allowable Uses of Scholarship Funding (SSDS-95/SPDS-34)

The vast majority of scholarships have some restrictions on the purposes for which the award can be used. Uses are often restricted to tuition and books. However, the allowed uses sometimes include interesting values such as travel, tutoring, and similar.

Change Detail

Added a new Allowed Funding Use Description free text element.

We considered adding a structured entity with enumerated funding use types. However, we’re not confident that applicants would find a detailed coding more useful than plain text, and we’re not sure that a fine-grained coding would support meaningful analysis. So, we’re proposing an unstructured text field for this version which we can change to a more structured approach if we get feedback from users that it would be useful.

Usage Detail

Similar to the current Eligibility Criteria Description element, we expect to enter values as a list (using markdown).

Example contents are shown in the JSON snippet below (\n indicates a line break):

Add Ability to Indicate Alumnus Requirement (SSDS-105/SPDS-29) (New 1/2)

In what seems like a glaring oversight, the current model has no support for an alumnus requirement.

Change Detail

Added a school indicator to the “Graduation Status” eligibility criteria.

• The Graduation Statuses was formerly just a single-value element with a degree or status. This change means that the GraduationStatuses element has changed to an entity (i.e., a JSON object/XML complex type).

• Per the usual pattern in the model, the updated entity includes a School entity, which contains elements such as NCES Code, CEEB Code, address information, and a school type in addition to the School Name.

An example XML data snippet follows. The criteria indicate an applicant must have graduated from Austin High School to be eligible for an award:

Add Program Contact Information (SSDS-115/SPDS-27) (New 1/3)

Many programs publish contact information for a program. Occasionally, that information is essential for applicants. For example, some community foundations administer and list programs that have deadlines or eligibility criteria available by contact only. The current Scholarship Exchange data model does not contain a structured way of storing contact information related to a listing.

Change Detail

For Scholarship Exchange v1.0d, we’ve added a new Program Contact entity.

• The entity contains:

  • Contact Name or Department. Often, the contact information doesn’t provide a human name, but rather a department (e.g., “Financial Aid Office”).

  • E-mail. Usually a general information inbox (e.g., “programs@example.edu”).

  • Phone. Seldom, but occasionally, listed.

• All elements are optional. The most common scenario is a simple e-mail address.

Usage Detail

• By definition, this is intended to convey public information. Any information should be provided by the program organization.

• Conversely, private or unpublished contact information should not be included, even if known by the data entry personnel or organization.

• Further, this entity is not intended to store a general e-mail inbox or phone number for an organization. In other words, the information should be specific to a scholarship offering or program, not, say, the main phone number of a multinational corporation.

• The specific + public information requirement means that many programs will not have this information, which is by design.

• The Name and Department do not need to be contextualized if an organization name is present. That is, if the organization is “Acme University” then the NameOrDepartment element may simply say, “Financial Aid Office” (as opposed to “Acme University Financial Aid Office”).

As noted, the typical example is a simple, general e-mail address and maybe a department or office. The following JSON snippet shows this typical usage:

Add Application Cycle Indicator (SSDS-92/SPDS-25)

Many scholarship programs make awards every year. The program name, purpose, and core characteristics mostly remain the same year over year, but values do change. For example, long-running major programs typically raise their award amount over time, online application links change, and so forth. Although most scholarship listing services simply use the most current information, many organizations and analysts desire to see the change over time for scholarship programs.

This change will add a value indicating the scholarship application cycle to which a particular record applies, allowing systems to support historical and longitudinal analysis of programs over time.

Change Detail

For Scholarship Exchange v1.0d, we’ve added a new Application Cycle element to the model.

The value should follow the school academic year format (e.g., 2019-2020).

Usage Detail

The following general rules apply to this element:

• The element is optional. If a value is not present, the record is assumed to be the current record.

• Typically, the scholarship application cycle will precede the academic year in which an award will be used (e.g., awards made in the 2019-2020 application cycle will be used by scholars in the 2020-2021 academic year).

• Notionally, the application cycle starts August 1 and ends July 31 the following year — with the vast majority of programs both opening and closing between those dates. For example, in 2019, Dell Scholars Program opened October 1 and closed December 1, which puts it squarely in the 2019-2020 application cycle.

• A program that’s always open will typically have multiple records. For example, a program that was open throughout calendar years 2018 and 2019 will have one record for 2018-2019 and another for 2019-2020.

The following XSD snippet shows the definition of the Application Cycle element:

The following XML snippet shows the new Application Cycle value:

Add Award Duration and Renewability Information (SSDS-96/SPDS-43)

Many scholarship programs have important properties related to the award duration. For example, it’s useful to know whether a program’s award is for a single year, or can be used across multiple years. For those programs that only offer single-year awards, it’s useful to know whether an applicant may re-apply for a subsequent award.

Change Detail

For Scholarship Exchange v1.0d, we’ve added the following information to the model:

• An award duration type. To indicate the time period over which the award may be used. Values include “One-Time” (indicating a single point in time), “Multiyear” (indicating that the award spans multiple years), and “Renewable” (meaning that the award is a one-time award, but applicants are explicitly allowed to re-apply for subsequent years).

• An award duration. For multiyear programs, indicates the number of years across which the award may be used. For renewable programs, indicates the number of renewal opportunities.

The following JSON snippet shows an example for a 4-year scholarship.

Add Scholarship Program Self-Description (SSDS-93/SPDS-47)

The Scholarship Exchange specification has had a Blurb since the first release. The Blurb is typically edited by Exchange administrators for consistency in voice, style, terminology, length, third-person perspective, and so forth. However, it’s useful for administrators — and potentially others — to see exactly how a program describes itself. This allows administrators doing QA to ensure important nuance isn’t missing from the Blurb or the Eligibility Criteria Detail. In addition, some programs that provide data may actively desire to have their own description shown to users.

Change Detail

For Scholarship Exchange v1.0d, we’ve added a new Program Self-Description element to the model:

• The element is a long string (which currently holds up to 4000 characters).

Usage Detail

• The following general rules apply to this element:

  • By design, the Self-Description should reflect what the providing organization wants to say about itself. Accordingly, the Self-Description will only receive light copy editing. It will not be rewritten for style, perspective, and so forth.

  • Most current consumers will prefer the Blurb to the Program Self-Description. Any that do receive and publish the self-description to end-users must frame the description accordingly (e.g., “From the Dell Scholars Program” or similar), to make clear the source of information and “who” is talking (e.g., so it’s clear who “we” are, if the self-description uses the first person).

• The NSPA Exchange will systematically record and review the value in advance of providing it to third parties (i.e., the value will be omitted from sharing until verified by NSPA Members and the NSPA data team). This will allow a trial period to ensure the quality, consistency, and value of the information.

The following XML snippet shows an example Program Self-Description:

Add Award Announcement Date (SSDS-88/SPDS-15)

Applicants are, understandably, curious to know when they can expect to hear whether or not they’ve been awarded a scholarship. Also, the length of time between an application close an the announcement is an interesting comparison point between programs.

Change Detail

For Scholarship Exchange v1.0d, we’ve added an Announcement Date element As one might expect, the format is a date string (e.g., “2019-11-11”).

Usage Detail

• Ideally, the date that individual applicants are notified. If that value is unknown, the date that awards are posted publicly (e.g., on the program website) or shared (e.g., via notice on bulletin board, telegram, whatever).

• It’s okay to enter an approximation, if known within a few week span. Just use the latest date in the approximate range. We don’t want to freak out applicants or make work for program administrators.

• Prefer leaving the value blank if it’s “sometime before summer.”

The Announcement Date value is grouped with other program date values as shown in the XML snippet below:

Add Support for Future or Intended Profession (SSDS-99/SPDS-31)

The current Scholarship Exchange data model has a Profession field, but the semantics mean that it's an applicant's current career. More often, we see requirements around a student's future or intended profession.

Change Detail

We made a semantic change to the existing “Current Profession” entity. The entity is now a general “Profession” indicator, with a boolean flag to indicate that the applicant must be currently practicing the profession.

The following XSD listing shows the latest entity definition, with changes noted in comments:

Note also that the reference in Eligibility Criteria was accordingly changed from “CurrentProfession” to “Profession”.

Add Country to Location Eligibility Criteria (SSDS-87/SPDS-46)

The Scholarship Exchange has a Location Eligibility Criteria to indicate geographic area eligibility requirements for a program. The current model has City, County, and State or Province elements. The next generation of the Exchange will support programs from other countries, so a Country indicator will be useful.

Change Detail

For Scholarship Exchange v1.0d, we’ve added a Country element to Eligibility Location. The format is a short string containing the ISO-3166 2-letter country code (e.g., CA, US, MX).

Usage Detail

• Country should be present when other Location Criteria are present.

• Country is NOT required for every listing, even if when implicit from other eligibility criteria.

  • For example, a U.S.-based program requiring U.S. citizenship can be inferred to have a Location Criteria where the Country is “US”. Nevertheless, a Location Criteria should not be added unless other explicit location restrictions are present.

  • This may change over time — but other elements and conventions are currently used to make this kind of national-level contextual filter.

The following JSON snippet shows an example of the Country element in use in the Locations entity:

Change Marines to Marine Corps in Armed Services List (SSDS-111/SPDS-36)

The Scholarship Exchange standard incorrectly lists the Marine Corps as “Marines” in the list of armed services.

Change Detail

For Scholarship Exchange v1.0d, we changed “Marines” to “Marine Corps” in the Armed Service List enumeration.

The following XSD snippet shows the new value in context:

Add GED Indicator & Make Consistency Updates to Graduation Status List (SSDS-109/SPDS-22) (New 12/14)

The Scholarship Exchange standard does not currently have a specific eligibility criteria representing GED or other high school equivalency. While this can be inferred by “High School Graduate,” some programs are explicitly for those with a GED, so it’s useful to have a separate representation.

Change Detail

For Scholarship Exchange v1.0d, we:

• Added an enumeration item “GED or High School Equivalency” to the Graduation Status List enumeration.

• Changed “High School Graduate, No Prior College” to “High School Graduate - No Prior College“ and “High School Graduate, No Prior Degrees” to ““High School Graduate, No Prior Degrees” (i.e., swapped the comma for a hyphen) to match the enumeration subcategorization style elsewhere in the standard.

The following JSON Schema snippet shows the new values in context:

Usage Detail

• For the majority of programs, the value “High School Graduate” implicitly includes students who have graduated based on a GED or high school equivalency exam. Accordingly, when coding criteria, we reserve use of the “GED or High School Equivalency” item for programs that are targeted toward that specific population — and we don’t add it to every program that also has “High School Graduate” coded. When searching, applicants who indicate they have a GED or high school equivalency will find programs coded with “GED or High School Equivalency” as well as programs coded with “High School Graduate”.

Add California AB 540 Status to Citizenship Eligibility Requirements (SPDS-35)

Many programs in California allow or explicitly serve undocumented students who have no formal citizenship status in the U.S. A common requirement for those students is that they have AB 540 status.

Change Detail

For Scholarship Exchange v1.0d, we added an enumeration item “California AB 540” to the U.S. Citizenship Eligibility Criteria List enumeration.

The following XSD snippet shows the addition in context:

Add New Medium-Length String, Apply to Program Name & Program Common Name (SSDS-113/SPDS-16)

We’ve encountered a few programs in the field that have names longer than the 100 characters allowed by ShortString.

Change Detail

For Scholarship Exchange v1.0d, we’ve created a new Medium String definition and applied it to Program Name and Program Common Name.

• The minimum string length is 1, meaning that if the element is present is must not be (semantically) null.

• The maximum length is 512, long enough to support the longest program names we’ve seen, but significantly shorter than the 4000-character Long String.

Element and Entity Name Improvements (SSDS-78/SPDS-18) (New 1/5)

Technical reviewers noted that a few element and entity names were misleading.

Change Detail

From Scholarship Exchange v1.0d, we’ve changed the following element and entity Names:

• CollegePreferences and CollegePreferenceCriteria have been changed to CollegeAttendance and CollegeAttendanceCriteria to properly reflect the use in the eligibility criteria context.

• EligibilityCriteriaDetail has been changed to EligibilityCriteriaDescription to denote the text-based nature of the element.

• Similarly, AwardVerificationCriteria has been changed to AwardVerificationCriteriaDescription.

Improve Cardinality in Eligibility Criteria (SSDS-128/SPDS-9) (New 2/28)

This is a non-substantive, technical housekeeping update.

The Age criterion added in v1.0d is the first eligibility criterion where a single value is appropriate (i.e., the Age entity has a cardinality of 0..1). Implementations prior to v1.0d allowed both multiple entries (which was desirable) and also for the criterion sequence to be valid in any order (which was not intentional). This update explicitly sets the cardinality of each criterion entity, and also requires that the criteria appear in a set order (alphabetically, by entity name).

Practically speaking, this change is expected to have zero real-world consequence: every record in the current NSPA Exchange appears to enforce the specified sequence.

Change Detail

The maxOccurs=”unbounded” was removed from the xs:sequence defining the eligibility criteria detail in the XSD schema. Rather, maxOccurs was set at the individual criteria. The new Age criterion was set to maxOccurs=”1”. All other criteria were set to maxOccurs=”unbounded”. That’s it.