HESA Student record 2012/13

Back to C12051

Validation overview

Version 1.1 Produced 2013-01-10

HESA has developed extensive quality assurance procedures and runs a range of validation checks against all submissions. The nature of some of these checks changes with the move to XML. This document describes the validation checks and the stages at which they take place.

XML files must be encoded with UTF-8 if they contain characters beyond the standard ASCII character set. Institutions are advised to specify the encoding used in their XML files (i.e. <?xml version="1.0" encoding="UTF-8" ?>) and to ensure that their files are actually saved with that encoding. Files with an explicit encoding declaration other than UTF-8 will be rejected. Files with undeclared encoding will be assumed to be UTF-8. If encoding is not specified or does not match the actual file encoding, institutions are warned that there is a risk that data contained in the files may be changed on submission to HESA.

Validation check	Stage
UKPRN validation at INSERT	INSERT
Schema checks	INSERT (included in Validation kit)
Business rules	INSERT (included in Validation kit)
HIN validation at INSERT	INSERT
HIN validation at COMMIT	COMMIT
COMMIT Validation (non-HIN checks)	COMMIT

Top

INSERT-Stage validation

UKPRN validation

The check to ensure that Institution.UKPRN is valid, is now carried out at INSERT rather than COMMIT.

If an invalid UKPRN is submitted, only this error will be displayed. The system will not display structural errors (schema checks) or business rule errors/warnings until a valid UKPRN is submitted.

Validation kit checks

HESA provide downloadable validation kits to assist institutions in the preparation of their data. The validation kits provide some basic structural and 'sense' checks prior to data submission with the aim of reducing the number of errors encountered when submitting data to the live system. With the change in structure for the student data, a new type of the student validation kit is required.

The new validation kit will perform two different types of checks:

Schema checks

Checks that the XML is 'well formed' and that it conforms to the rules of the schema definition (the XSD files)

Examples:

Every element in the file must have the correct opening and closing tags
Elements must be correctly nested
Elements must contain the correct type of data (strings, dates, valid entries etc.)
Elements that include characters with special meaning in XML (such as greater than, & ampersand, ' apostrophe and " quotation mark) must be replaced with the appropriate entity reference. Further information is available at: http://www.w3schools.com/xml/xml_syntax.asp
Elements must be submitted in the sequence defined in the XSD

Business rules

A set of rules to check the business logic of the submission.

Examples:

Consistency between pairs or groups of elements
Elements that are compulsory under certain circumstances
Range checks

Business rules can only be carried out when all structural errors (schema checks) have been resolved. The individual business rules are listed in the specification document for each element.

Business rules can be switched off when running data through the validation kit, both locally and at HESA. Schema checks can never be switched off.

An overview of the INSERT stage validation is shown below.

Top

HIN Validation at INSERT

In addition to the checks within the validation kit, several HIN checks are also carried out at INSERT. HIN Validation at INSERT ensures that for students continuing on an instance, there is a record in a previous year's return that can be HIN linked to the record in the current year's return. Therefore where entry profile data is submitted at the start of the instance and not in subsequent years, these HIN INSERT checks ensure that such data can be found and linked to the incoming instance. HIN Validation at INSERT is as follows:

No HIN link for an incoming instance (submitted without Entry Profile) that commenced in a previous reporting period
Instance EntryProfile Exception 2 (Error) EntryProfile entity must exist where the corresponding Instance has not been previously reported (i.e. cannot be found on the HIN/EntryProfile register) and corresponding Instance.REDUCEDI = 00, 01, 03 or 04

Top

COMMIT-stage validation

COMMIT Validation (non-HIN checks)

A further stage of validation will continue to run as a part of the COMMIT transaction in the data collection system. COMMIT validation includes checks that require comparison with data across an entire return. Additionally, several HIN checks are also carried out at COMMIT.

HIN Validation at COMMIT

HIN Validation at COMMIT ensures that records on the HIN Target List, generated from the previous year's return, are included in the current year's return. Also, where entry profile data is submitted at the start of the instance as well as in subsequent years, HIN Validation at COMMIT ensures that such data does not change and is as on entry to the course (unless corrections are being made or unknown values are being populated).

The Commit-stage validation checks are listed in a separate document.

An overview of COMMIT stage validation is shown below.

Top

Validation kit software

A schema-only validation kit is available for download as an MSI installation file. To install the software you simply need to run the MSI file on a Windows PC. If you do not have access to a Windows PC, please contact Institutional Liaison ([email protected]) for further instructions.

When the validation program is opened it automatically checks the HESA web server for the latest set of rules and updates the package if appropriate.

A quick start guide is included in the application.

The kit utilises the Microsoft .NET framework. This is likely to already be installed on many computers as it is required by much of Microsoft's own software. You can download the .Net framework from Microsoft's website.

If you have any queries with regard to the validation kit then please contact Institutional Liaison ([email protected]).