HESA Student Record 2008/09
HESA Student Record 2008/09
Glossary of terms
return to index
Version 1.0 Produced 2008-06-16
In any technical documentation certain terms must be clearly defined in order to achieve a common understanding of the principles and concepts covered. The following terms need to be understood in order to fully understand the specification of the record.
The specification of the Student Record begins with the data model. A data model (sometimes known as an Entity Relationship Model) defines the entities covered by the specification and the relationship between the entities.
Entities have attributes; for example, gender is an attribute of a student. Therefore, a field is an attribute of an entity. This documentation uses the structure Entity.SHORTFIELDNAME (e.g Student.GENDER) when referring to specific fields.
The Student Record must be submitted as an XML (eXtensible Markup Language) file. An XML file contains elements. An element is identified using tags (defined with 'pointy brackets') and each element must have a start tag and an end tag. Each tag contains the element name and the end tag also contains a / character.
Elements can contain data; for example, a birth date element might look like this:
Elements can be nested within other elements to represent hierarchical data structures. Therefore, in the HESA Student Record an element can be an entity or an attribute (i.e. a field). For example, this Student entity has attributes of name and date of birth:
<Student> <FNAMES>Joeseph William</FNAMES> <SURNAME>Bloggs</SURNAME> <BIRTHDTE>1975-06-18</BIRTHDTE> </Student>
XML Schema Definition (XSD)
The specification of an XML structure is contained in an XML Schema Definition (XSD) file. This defines the elements, their optionality and their structure. Specifically:
- The XSD defines the minimum and maximum occurrences for each element. If the minimum is one then the element has to be present in every case; a value of zero implies that there are cases where this element does not occur - these will be controlled through validation rules.
- The XSD defines the nesting of elements - which in this case means defining which fields belong to which entity as well as defining the hierarchical structure of the entities.
- The XSD defines the data types. This includes defining lists of valid entries, charactersets for name fields as well as defining which fields are date or numeric.
- The XSD defines the order that elements must appear in within submitted files. This can be different to the order that they are presented within the coding manual
Institutions will be able to use freely-available software called a validating parser to compare their XML files against the XSD. This will perform many (though not all) of the validation checks that were previously undertaken by the validation kits.
Detailed Specification Documentation
The documentation produced to support the specification of the record includes a formatted list of the elements (both entities and fields) and a full description of each element. The index page includes a simple menu bar to filter elements by country.
The pages that describe the elements follow a standard format, which is shown below. Not every category shown below applies to every element.
|Short name||The abbreviated version of the element name. The short names for the entities conform to the naming principles of ISO11179; the short field names have, where possible, been kept consistent with the previous Student Record specification.|
|Type||Type will either be field or entity. The entity type includes nested elements which hold repeating groups of fields.|
|Description||A brief description of the element.|
|Applicable to||This lists to countries that the element applies to.|
|Coverage||This defines when the element must be completed.|
|Base data type||The XML data type for this element. The specification of XML includes a number of simple data types which begin xs:. All other data types are defined by HESA in the XML schema definition files.|
|Field length||This is a maximum field length. Other rules about the structure of an element are enforced through the specification of the data type.|
|Part of||The parent element that owns this element.|
|Minimum occurrences||The minimum number of times this element can occur in the parent element. This value will be set to zero when other (more complex) coverage rules apply.|
|Maximum occurrences||The maximum number of times this element can occur in the parent element.|
|Has parts||When an element contains nested elements, they are listed here.|
A list of related elements.
|Reason required||A statement of the reason this element is required.|
|Examples||Examples to aid understanding.|
|Notes||Notes and further guidance.|
|Owner||The organisation or body that owns the specification of this element.|
|Version||A version number to aid change management.|
|Based on||Any external standard or specification that provides the basis for this specification.|
|Schema components||Links to the parts of the XML schema definition that are relevant to this element. These links open in a new window.|
|Change management notes||Notes to record changes between versions.|
|Valid entries and labels||Where applicable, a full list of the valid entries and labels is included.|
Contact Liaison by email or on 01242 211144.