Alternative provider student record 2016/17 - File structure
Version 1.1 Produced 2016-11-24
The physical file structure to be returned to HESA is based on the logical data model but with either repeating elements or specific field requirements expressed separately. The file structure is designed to be future-proof in that it will support incremental submission of data throughout a reporting period with only minimal change: the separation out of data items is designed to allow this.
The elements are:
|Logical data model concept||Entity||Sub-entity||Description|
|Course||Course||Course Subject||A JACS subject code and a proportion indicator|
|Student||Student||StudentEquality||Data items which are required for monitoring equality, applicable to designation submissions only|
|Student-Course engagement||Student||EntryProfile||Data items which relate to the student at the outset of their engagement with a course|
|EntryProfile||QualificationsOnEntry||Qualifications held at the outset of the engagement, returnable many times|
|Student||Instance||Data items which relate to the entirety of an instance of engagement between student and course|
|Instance||InstancePeriod||Data items which pertain to a particular cycle within an instance of engagement|
|InstancePeriod||QualificationsAwarded||Qualifications awarded during the instance period|
Data must be returned to HESA as an XML file. XML is the eXtensible Markup Language and is a W3C recommendation. There are many XML training resources on the web, including the W3C Tutorial on XML and the resources of W3Schools.
Files must be encoded with UTF-8 and schema validation will be in place to ensure this. Institutions must specify the encoding used in their XML files in the first line of the file (i.e. <?xml version="1.0" encoding="UTF-8" ?>) and to ensure that their files are actually saved with that encoding. If XML files are edited with some text editors and the encoding is not specified or does not match the actual file encoding, there may be problems when submitting these files for validation.
Ordering of attributes for submission
The order in which entities and fields should be submitted is governed by the C16054.xsd file, which is ordered according to the following principles:
- Entities are presented in parent-child order, starting with the 'Provider' entity.
- Fields within entities are presented in the order of primary key fields, candidate key fields, foreign key fields, and non-key fields.
- Child entities then follow.
- Each field or entity within a parent entity is presented in alphabetical order to aid their location.
Further guidance about data items is available in the Further guidance on file structure for submission document.
Contact Liaison by email or on 01242 211144.