| IMS Learner Information Packaging Best Practice & Implementation Guide Final Specification Version 1.0

Copyright © 2001 IMS Global Learning Consortium, Inc. All Rights Reserved.

The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name:IMS Learner Information Packaging Best Practice & Implementation Guide v1.0
Revision: 9 March 2001

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2001 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

# Table of Contents

ABOUT THIS DOCUMENT
LIST OF CONTRIBUTORS
REVISION HISTORY
LIST OF FIGURES
LIST OF TABLES

1. INTRODUCTION
  1.1 IMS LEARNER INFORMATION SPECIFICATIONS OVERVIEW
  1.1.1 Requirements
  1.1.2 Learner Information Data and Meta-data
  1.1.3 Learner Data Structure
  1.1.4 Learner Information Meta-data
  1.2 SCOPE & CONTEXT
  1.3 STRUCTURE OF THIS DOCUMENT
  1.4 NOMENCLATURE
  1.5 REFERENCES

2. RELATIONSHIP TO OTHER SPECIFICATIONS
  2.1 IMS SPECIFICATIONS
  2.2 RELATED SPECIFICATIONS
  2.2.1 IEEE P1484
  2.2.2 Schools Interoperability Framework (SIF)
  2.2.3 ANSI TS 130 Student Educational Record
  2.2.4 Internet vCard Specification
  2.2.5 Internet2 eduPerson
  2.2.6 HR-XML Consortium Specifications
  2.3 RELATED ACTIVITIES
  2.3.1 ISO/IEC JTC1/SC36 Learning Technology
  2.3.2 Advanced Distributed Learning (ADL) Initiative
  2.3.3 Aviation Industry CBT Committee (AICC)
  2.3.4 EU ACTS Gestalt Project
  2.3.5 CEN/ISSS
  2.4 IMS SPECIFICATION DEVELOPMENT PROCESS

3. OVERALL DATA MODEL
  3.1 INFORMATION MODEL
  3.2 XML SCHEMA TREE
  3.2.1 Core XML Schema Tree
  3.2.2 <identification> XML Schema Tree
  3.2.3 <goal> XML Schema Tree
  3.2.4 <qcl> XML Schema Tree
  3.2.5 <accessibility> XML Schema Tree
  3.2.6 <activity> XML Schema Tree
  3.2.7 <competency> XML Schema Tree
  3.2.8 <interest> XML Schema Tree
  3.2.9 <transcript> XML Schema Tree
  3.2.10 <affiliation> XML Schema Tree
  3.2.11 <securitykey> XML Schema Tree
  3.2.12 <relationship> XML Schema Tree

4. BASIC EXAMPLE LIP INSTANCES
  4.1 ACCESSIBILITY EXAMPLES
  4.1.1 Accessibility Language Examples
  4.1.2 Accessibility Preference Examples
  4.2 ACTIVITY EXAMPLES
  4.2.1 Activity Learningactivetyref Examples
  4.2.2 Activity Definition Examples
  4.2.3 Activity Product Examples
  4.2.4 Activity Testimonial Examples
  4.2.5 Activity Evaluation Examples
  4.3 AFFILIATION EXAMPLES
  4.4 COMPETENCY EXAMPLES
  4.5 GOAL EXAMPLES
  4.6 IDENTIFICATION EXAMPLES
  4.6.1 Identification Formatted Name Examples
  4.6.2 Identification Name Examples
  4.6.3 Identification Address Examples
  4.6.4 Identification Contactinfo Examples
  4.6.5 Identification Demographics Examples
  4.6.6 Identification Agent Examples
  4.7 INTEREST EXAMPLES
  4.8 QCL EXAMPLES
  4.9 RELATIONSHIP EXAMPLES
  4.10 SECURITYKEY EXAMPLES
  4.11 TRANSCRIPT EXAMPLES

5. ADVANCED EXAMPLE LIP INSTANCES
  5.1 ENGINEERING RESUME
  5.1.1 The Example
  5.1.2 The XML Instance
  5.1.3 Key Features of the Engineering Resume Example
  5.2 FEFC FUNDING RECORDS EXCHANGE
  5.2.1 The Example
  5.2.2 The Instance - Version 1
  5.2.3 The Instance - Version 2
  5.2.4 Key Features of the ISR Mapping Examples

6. IMS LIP AND OTHER RELEVANT SPECIFICATIONS
  6.1 IMS SPECIFICATIONS
  6.1.1 Enterprise
  6.1.2 Content Packaging
  6.1.3 Meta-data
  6.1.4 Accessibility
  6.1.5 Competency Definitions
  6.1.6 Question & Test Interoperability
  6.2 OTHER SPECIFICATIONS
  6.2.1 IETF vCard
  6.2.2 IEEE PAPI
  6.2.3 Internet2/Educase 'eduPerson'

7. IMPLEMENTATION GUIDANCE
  7.1 NOMENCLATURE
  7.2 USING THE CORE DATA STRUCTURES
  7.2.1 <accessibility>
  7.2.2 <activity>
  7.2.3 <affiliation>
  7.2.4 <competency>
  7.2.5 <goal>
  7.2.6 <identification>
  7.2.7 <interest>
  7.2.8 <qcl>
  7.2.9 <relationship>
  7.2.10 <securitykey>
  7.2.11 <transcript>
  7.3 LIP STRUCTURAL META-DATA
  7.3.1 Referential Structure
  7.3.2 Temporal Structure
  7.3.3 Privacy Structure
  7.4 THE LIP VOCABULARIES
  7.4.1 The Basic Vocabularies
  7.4.2 Extending the Vocabularies
  7.4.3 Data Entry Using the Vocabularies
  7.5 BUILDING RELATIONSHIPS WITHIN THE LIP
  7.6 IDENTIFIERS
  7.7 PACKAGING, TRANSACTIONS, MESSAGING & PROTOCOLS
  7.8 SECURITY ARCHITECTURES & CONSIDERATIONS
  7.8.1 LIP Identifiers
  7.8.2 Access Control
  7.8.3 Privacy
  7.8.4 Data Integrity
  7.8.5 Miscellaneous
  7.9 DISTRIBUTED ARCHITECTURES & CONSIDERATIONS

8. V2.0 ELEMENTS

9. EXTENSIBILITY

10. CONFORMANCE
  10.1 VALID DATA ISSUES
  10.2 CONFORMANCE STATEMENT
  10.2.1 Learnerinformation Conformance Statement Table
  10.2.2 Accessibility Conformance Statement Table
  10.2.3 Activity Conformance Statement Table
  10.2.4 Affiliation Conformance Statement Table
  10.2.5 Competency Conformance Statement Table
  10.2.6 Goal Conformance Statement Table
  10.2.7 Identification Conformance Statement Table
  10.2.8 Interest Conformance Statement Table
  10.2.9 Qcl Conformance Statement Table
  10.2.10 Relationship Conformance Statement Table
  10.2.11 Securitykey Conformance Statement Table
  10.2.12 Transcript Conformance Statement Table
  10.3 A CONFORMANCE STATEMENT EXAMPLE

APPENDIX A - LIP AND ITS SCHEMAS
  A1 OVERVIEW
  A2 FEATURES OF THE DIFFERENT DTDS/XDRS
  A3 RECOMMENDED USAGE OF THE XSDS AND DTDS
  A4 FULL DIRECTORY STRUCTURE

APPENDIX B - THE LIP XML INSTANCE EXAMPLE FILES

APPENDIX C - GLOSSARY OF TERMS
  C1 GENERAL TERMS
  C2 LIP ELEMENTS AND ATTRIBUTES

# List of Figures

FIGURE 1.1 THE IMS LEARNER INFORMATION PACKAGE (LIP) CORE DATA STRUCTURES.
FIGURE 3.1 THE IMS LIP DATA MODEL.
FIGURE 3.2 THE CORE XML SCHEMA TREE.
FIGURE 3.3 THE <IDENTIFICATION> XML SCHEMA TREE.
FIGURE 3.4 THE <GOAL> XML SCHEMA TREE.
FIGURE 3.5 THE <QCL> XML SCHEMA TREE.
FIGURE 3.6 THE <ACCESSIBILITY> XML SCHEMA TREE.
FIGURE 3.7 THE <ACTIVITY> XML SCHEMA TREE.
FIGURE 3.8 THE <COMPETENCY> XML SCHEMA TREE.
FIGURE 3.9 THE <INTEREST> XML SCHEMA TREE.
FIGURE 3.10 THE <TRANSCRIPT> XML SCHEMA TREE.
FIGURE 3.11 THE <AFFILIATION> XML SCHEMA TREE.
FIGURE 3.12 THE <SECURITYKEY> XML SCHEMA TREE.
FIGURE 3.13 THE <RELATIONSHIP> XML SCHEMA TREE.
FIGURE 6.1 SCHEMATIC REPRESENTATION OF THE FILES TO BE PACKAGED.
FIGURE 6.2 THE USAGE OF IMS LIP TO SUPPORT IEEE PAPI.
FIGURE 7.1 A SCHEMATIC MODEL OF LAYER-BASED COMMUNICATING PROFILE SERVERS.

# List of Tables

TABLE 5.1 ISR MAPPING TO THE IMS LIP.
TABLE 6.1 THE USAGE OF IMS LIP TO SUPPORT THE IETF VCARD SPECIFICATION.
TABLE 6.2 THE USAGE OF IMS LIP TO EXCHANGE THE EDUPERSON INFORMATION
TABLE 8.1 LIST OF V1.X/2.0 SPECIFIC ELEMENTS.
TABLE 9.1 LIST OF PROPRIETARY EXTENSION ELEMENTS.
TABLE 10.1 LEARNERINFORMATION CONFORMANCE STATEMENT TABLE.
TABLE 10.2 ACCESSIBILITY CONFORMANCE STATEMENT TABLE.
TABLE 10.3 ACTIVITY CONFORMANCE STATEMENT TABLE.
TABLE 10.4 AFFILIATION CONFORMANCE STATEMENT TABLE.
TABLE 10.5 COMPETENCY CONFORMANCE STATEMENT TABLE.
TABLE 10.6 GOAL CONFORMANCE STATEMENT TABLE.
TABLE 10.7 IDENTIFICATION CONFORMANCE STATEMENT TABLE.
TABLE 10.8 INTEREST CONFORMANCE STATEMENT TABLE.
TABLE 10.9 QCL CONFORMANCE STATEMENT TABLE.
TABLE 10.10 RELATIONSHIP CONFORMANCE STATEMENT TABLE.
TABLE 10.11 SECURITYKEY CONFORMANCE STATEMENT TABLE.
TABLE 10.12 TRANSCRIPT CONFORMANCE STATEMENT TABLE.
TABLE 10.13 EXAMPLE LEARNERINFORMATION CONFORMANCE STATEMENT TABLE.
TABLE 10.14 EXAMPLE IDENTIFICATION CONFORMANCE STATEMENT TABLE.
TABLE 10.15 EXAMPLE QCL CONFORMANCE STATEMENT TABLE.
TABLE B1 THE LIP XML INSTANCE VALID BASIC EXAMPLE FILES.
TABLE B2 THE LIP XML INSTANCE VALID ADVANCED EXAMPLE FILES.

# About This Document

Title | IMS Learner Information Package Best Practice & Implementation Guide
Authors | Colin Smythe, Frank Tansey and Robby Robson
Version | 1.0
Version Date | 9th March, 2001
Status | Final Specification.
Summary | This document provides additional information regarding IMS Learner Information Packaging best practices and implementation guidelines. It is meant to complement the IMS LIP XML Binding and IMS LIP Information Model documents.
Revision Information | 9th March, 2001
Purpose | Defines the best practice usage of the XML binding for the LIP Information Model specification.
Document Location | http://www.imsglobal.org/profiles/lipbest01.html.

# List of Contributors

The following individuals contributed to the development of this document:

Susan Beidler | PeopleSoft, USA
Geoff Collier | Saba Software, USA
Andy Heath | JISC/CETIS, UK
Wayne Martin | Miami-Dade Community College, USA
Bill Olivier | JISC/CETIS, UK
Tom Probert | Enterprise Computing, USA
Robby Robson | Saba Software, USA
Colin Smythe | Dunelm Services, UK
Frank Tansey | IMS, USA
Tom Wason | IMS, USA

# Revision History

Version No. | Release Date | Comments
Public Draft Specification v1.0 | 21st December, 2000 | This is the first publicly available version of the IMS LIP Best Practice & Implementation Guide.
Final Specification v1.0 | 9th March, 2001 | This is the first final version of the IMS LIP Best Practice & Implementation Guide.

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Learner Information Package Best Practice Guide ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsglobal.org/
Please refer to Document Name: IMS Learner Information Package Best Practice Guide v1 Revision: March 2001

# 1. Introduction

## 1.1 IMS Learner Information Specifications Overview

IMS Learner Information Package is based on a data model that describes those characteristics of a learner needed for the general purposes of:

- Recording and managing learning-related history, goals, and accomplishments;

- Engaging a learner in a learning experience;

- Discovering learning opportunities for learners.

The specification supports the exchange of learner information among learning management systems, human resource systems, student information systems, enterprise e-learning systems, knowledge management systems, resume repositories, and other systems used in the learning process. In this document such systems will be called learner information systems regardless of any other functionality they possess or roles they fulfil. The IMS Learner Information Package specification does not address requests for learner information or the exchange transaction mechanism.

### 1.1.1 Requirements

IMS Learner Information specifications are designed to meet the following requirements:

- Distributed information: A learner information system may in fact consist of multiple distributed systems that share learner information or that store learner information in a distributed fashion. This necessitates the inclusion of adequate indexing and time stamping of learner information data as it is packaged;

- Scalability: To support large-scale systems it is necessary to exchange and reassemble chunks of arbitrary granularity as well as bulk transfer. Packaging of multiple LIPs will use the IMS Content &Packaging specification;

- Privacy and Data Protection: Learner information systems must be able to implement privacy and data protection policies and insure the integrity of data;

- Flexibility and External references: Learner information includes many constructs, such as learning objectives and learning history, which are in practice represented by different structures in different contexts. Learner information data models must be flexible enough to accommodate this need.

#### Privacy and Data Protection

The IMS project recognizes the need to:

- Maintain the privacy of learner information;

- Protect information from inappropriate access;

- Ensure the integrity of information;

- Accommodate the regulatory policies and requirements of different jurisdictions.

IMS Learner Information Package enables the inclusion of mechanisms for maintaining privacy and protecting the integrity of data with all data that comprises learner information. The specification cannot, however, specify the form, format, or type of these mechanisms or policies for their use. These must be determined by specific implementations in accordance with their requirements.

### 1.1.2 Learner Information Data and Meta-data

IMS Learner Information Package is a structured information model. An XML binding is included but is not meant to exclude other bindings. The information model contains both data and meta-data about that data. The model defines fields into which the data can be placed and the type of data that may be put into these fields. Typical data might be the name of a learner, a course or training completed, a learning objective, a preference for a particular type of technology, and so on. Meta-data about each field can include:

1. Time-related information;
2. Identification and indexing information;
3. Privacy and data protection information.

This meta-data is available for each and every field in the information model, either directly or via inheritance.

### 1.1.3 Learner Data Structure

The learner information model can be viewed in three different ways:

1. A tree;
2. An object model;
3. A tabular representation.

All three ways are explained in the specification. The Learner information is separated into eleven main categories (as shown in Figure 1.1). These structures have been identified as the primary data structures that are required to support learner information. This composite approach means that only the required information needs to be packaged and stored.

Figure 1.1 The IMS Learner Information Package (LIP) core data structures.

- Identification: Biographic and demographic data relevant to learning;

- Goal: Learning, career and other objectives and aspirations;

- Qualifications, Certifications and Licenses (qcl): Qualifications, certifications and licenses granted by recognized authorities;

- Activity: Any learning-related activity in any state of completion. Could be self-reported. Includes formal and informal education, training, work experience, and military or civic service;

- Transcript: A record that is used to provide an institutionally-based summary of academic achievement. The structure of this record can take many forms;

- Interest: Information describing hobbies and recreational activities;

- Competency: Skills, knowledge, and abilities acquired in the cognitive, affective, and/or psychomotor domains;

- Affiliation: Membership of professional organizations, etc. Membership of groups is covered by the IMS Enterprise specification;

- Accessibility: General accessibility to the learner information as defined through language capabilities, disabilities, eligibilities and learning preferences including cognitive preferences (e.g. issues of learning style), physical preferences (e.g. a preference for large print), and technological preferences (e.g. a preference for a particular computer platform);

- Securitykey: The set of passwords and security keys assigned to the learner for transactions with learner information systems and services;

- Relationship: The set of relationships between the core components. The core structures do not have within them identifiers that link to the core structures. Instead all of these relationships are captured in a single core structure thereby making the links simpler to identify and manage.

These categories were chosen to meet the requirements of a large variety of use cases and to facilitate mapping among IMS and other relevant specifications. Within each category several data elements and structures are defined. Some of these are specified explicitly as data types (language strings, for the most part) and others are defined as recursive hierarchical structures. In addition, data may be defined by referencing mechanisms. The referencing mechanisms supported are internal references, references to an external learner information system, and references via a URI.

### 1.1.4 Learner Information Meta-data

The learning information meta-data (contained within the ‘contentype’ structure shown in Figure 1.1) is broken into four categories:

- Time Information: Time of creation and time of expiration of a piece of data;

- Index and Source: Supports a pair consisting of a source and an ID assigned by that source, a local index that is used for cross-referencing, and a URI;

- Privacy and data protection information: Unstructured data to be determined by practice and implementation.

All learning information data elements have meta-data sub-elements with the exception of atomic elements that can always inherit their meta-data. For example, in the Identification category, meta-data is associated with the Name element but not with its constituent elements since it is felt that the meta-data for the constituent elements cannot change independently of the meta-data for the Name element itself.

## 1.2 Scope & Context

This document is the IMS Learning Information Package (LIP) Best Practice & Implementation Guide. As such it should be used in conjunction with the:

- IMS Learner Information Package Information Model specification v1.0;

- IMS Learner Information Package XML Binding v1.0;

## 1.3 Structure of this Document

The structure of this document is:

2. Relationship to Other Specifications | The relationship of this specification to other IMS and external specification activities;
3. Overall Data Model | A brief summary of the IMS Learner Information Packaging information model;
4. Basic Example LIP Instances | Examples of the basic LIP instances (for each of the core structures) that are supported by this specification;
5. Advanced Example LIP Instances | Advanced examples of LIP instances that are supported by this specification;
6. IMS LIP and Other Relevant Specifications | An explanation of how the IMS LIP can be used to capture some of the other relevant specifications;
7. Implementation Guidance | Tips on how distributed learning systems can make best usage of the LIP specification;
8. V1.x Developments | The areas of the specification that are for further development in later releases;
9. Extensibility | The extension facilities and their usage;
10. Conformance | The expectations on systems that claim conformance to the IMS LIP specifications;
Appendix A – LIP and its Schemas | The range of available LIP XSDs and DTDs;
Appendix B – The LIP XML Instance Example Files | The set of LIP examples and their associated file names;
Appendix C – Glossary of Terms | A glossary of the key terms and elements used within the specification.

## 1.4 Nomenclature

ADL Advanced Distributed Learning

AICC Aviation Industry CBT Committee

ANSI American national Standards Institute

CBT Computer Based Training

CEN Centre for European Normalisation

CORBA Common Object Repository Brokerage Architecture

DCOM Distributed Common Object Management

DTD Document Type Definition

EDI Electronic Data Interchange

FEFC Further Education Funding Council

GUID Global User Identifier

IEEE Institute of Electronic & Electrical Engineering

IETF Internet Engineering Task Force

ISO International Standards Organisation

ISR Individualised Student Record

ISSS Information Society Standardisation Service

JTC Joint Technical Committee

LDAP Lightweight Directory Access Protocol

LIP Learner Information Packaging

LOM Learner Object Meta-data

LTSC Learning Technology Standards Committee

NATO North Atlantic Treaty Organisation

PAPI Public And Private Information

PDI Personal Data Interchange

QTI Question & Test Interoperability

SCORM Shareable Courseware Object Reference Model

SEP Staffing Exchange Protocol

SIF Schools Interoperability Framework

URI Universal Resource Identifier

W3C World Wide Web Consortium

XDR XML Data Reduced

XML Extensible Mark-up Language

XSD XML Schema

## 1.5 References

[ANSI, 98] Student Educational Record (Transcript), ANSI ASC X.12-TS130, ANSI, April 1998.

[CP, 00a] IMS Content Packaging Information Model, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00b] IMS Content Packaging XML Binding, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00c] IMS Content Packaging Best Practice and Implementation Guide, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[eduPerson, 01] EduPerson 1.0 Specification, Internet2/Educause, Feb 2001.

[Enterprise, 99a] IMS Enterprise Information Model, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise, 99b] IMS Enterprise XML Binding, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise, 99c] IMS Enterprise Best Practice and Implementation Guide, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Gestalt, 00] Gestalt: WP4 - Integrating IMS Enterprise, PAPI and Gestalt UOM Data Models, version 3.0, P.Foster, Gestalt Doc No: FC:/MAN/REPORTS/022GESTALT/D401/GestaltEnterprisePAPI_3, March 2000.

[Gestalt, 99] Gestalt: WP5 - Object (Interfaces) Specification, V.Wade, K.Riley, B.Banks, P.Foster, N.Evans-Mudie, Y.Nicol, P.Doherty, Gestalt Doc No: A367/TCD/WP05/DS/L/008/b1, October 1999.

[HR, 00a] Resume DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[HR, 00b] Candidate DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[LIP, 00a] Profiles Interchange Requirement Specification, G.Collier, T.Probart and C.Smythe, Version 1.0, IMS, March 2000.

[LIP, 01a] IMS Learner Information Package Information Model Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[LIP, 01b] IMS Learner Information Package XML Binding Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[LIP, 01c] IMS Learner Information Package Best Practices & Implementation Guide Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[MD, 99a] IMS Meta-data Information Model, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99b] IMS Meta-data XML Binding, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99c] IMS Meta-data Best Practice and Implementation Guide, T.Wason, Version 1.0, IMS, September 1999.

[Messaging, 99] Proposal for the Inclusion of a Run Time Messaging Service in the IMS 1.0 Specifications, Ken Schweller, IMS, May 1999.

[PAPI, 98] IEEE PAPI Specification - Learning Technology: Public and Private Information, Version 6.0, IEEE LTSC P1484, June 2000.

[QTI, 01] IMS Question & Test Interoperability Information Model, C.Smythe and E.Shepherd, Version 1.1, IMS, March 2001.

[Saba, 00] Profile Format: Design Specification, Daniel Lipkin, Saba Inc, May 2000.

[SIF, 99] Schools Interoperability Framework Preliminary Implementation Specifications, Version 1.0, SIF, November 1999.

[vCard, 98] The vCard v3.0 XML DTD, F.Dawson, IETF Draft, June 1998.

# 2. Relationship to Other Specifications

## 2.1 IMS Specifications

Version 1.0 of the IMS Learner Information Package (LIP) specification is made up of three documents:

- IMS Learner Information Package Information Model – Version 1.0. This document describes the data structures that are used to provide interoperability of Internet-based learner information systems;

- IMS Learner Information Package XML Binding – Version 1.0. This document describes how to encode the learning information objects in XML and provides the corresponding XML schema;

- IMS Learner Information Package Best Practice & Implementation Guide – Version 1.0. This document (the one you are reading now) provides an overview and describes how the IMS LIP Information Model and XML Binding can be applied to specific types of interoperability scenarios.

The IMS LIP specification is related to several other IMS specifications, both complete and in-progress. This specification is intended to be consistent with these other initiatives wherever possible, in order to reduce redundancy and confusion between specifications. The related specifications are:

- IMS Meta-data Specification – the IMS LIP specification recommends the usage, where appropriate, of the IMS Meta-data definitions to support the meta-data entities to be used in the context of the LIP;

- IMS Enterprise Specification – the IMS LIP is not to be used for the exchange of information concerning education groups and the membership of such groups. This type of information exchange should be based on the IMS Enterprise specification;

- IMS Content Packaging Specification – multiple IMS LIP XML instances should be packaged using the IMS Content Packaging mechanisms;

- IMS Question & Test Interoperability – summary results interoperability is support by the IMS LIP. This will also be addressed by the IMS QTI working-group and when their work has been completed the two solutions will be formally harmonised (IMSP LIP method is more generic that that proposed for the QTI and as such is capable of supporting the QTI method).

## 2.2 Related Specifications

### 2.2.1 IEEE P1484

The IEEE Learning Technology Standardisation Committee P1484 is the only body engaged in the educational domain, which has a recognised formal standing. Given the diversity of the fora represented by the participants in the IEEE, there exist a large number of working groups focused on specific activities, as well as more horizontal activities (such as the Architecture and Reference Model and the Glossary working groups) that attempt to tie the wider ranging work together. The IEEE Public & Private Information (PAPI) Specification is an attempt to define a ‘portable’ learner [IEEE, 98]. The IMS LIP has, in part, been derived from the PAPI (versions 5.0 and 6.0).

### 2.2.2 Schools Interoperability Framework (SIF)

The Schools Interoperability Framework is an industry initiative to develop a technical blueprint for K-12 software that will enable diverse applications to interact and share data now and in the future. SIF has two deliverables: the SIF Message Specification and the Implementation Specification. While the SIF Message Specification defines the messages that each application can exchange with others, the Implementation Specification defines the software implementation guidelines for SIF. The Implementation Specification does not make any assumption of what hardware and software products need to be used to develop SIF-compliant applications. Instead, it only defines the requirements of architecture, communication, software components, and interfaces between them. The goal of SIF is to ensure that all the SIF-compliant applications can achieve interoperability, regardless of how they are implemented. SIF is truly an open industrial initiative. SIF is focused on supporting interoperability between schools-based educational administration systems whereas LIP is focussed on learner educational information.

### 2.2.3 ANSI TS 130 Student Educational Record

The ANSI TS130 contains the format and establishes the data contents of a Student Educational Record (Transcript) Transaction Set for use within the context of Electronic Data Interchange (EDI) environment. The student transcript is used by schools and school districts, and by post-secondary educational institutions to transmit current and historical records of educational accomplishment and other significant information for students enrolled at the sending schools and institutions. The transcript may be sent to other educational institutions, to other agencies, or to prospective or current employers. The student transcript contains personal history and identifying information about the student, the current academic status, dates of attendance, courses completed with grades earned, degrees and diplomas awarded, health information (Pre-Kindergarten through Grade 12 only), and testing information.[1]

### 2.2.4 Internet vCard Specification

The vCard specification allows the open exchange of Personal Data Interchange (PDI) information typically found on traditional paper business cards. The specification defines a format for an electronic business card, or vCard. The vCard specification is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point public switched telephone networks, wired-network transport, or some form of unwired transport. The vCard has direct application to the way users utilize the Internet network. The vCard can be used to forward personal data in an electronic mail message. The numerous forms a user of the WWW fills out on a homepage can also be automated using the vCard. The Internet Mail Consortium is working with the Internet Engineering Task Force (IETF) to complete work on an extension to the Internet MIME-based electronic mail standard to allow for this capability. An XML binding of the vCard specification has produced a DTD [vCard, 98] and this has been used to inform the development of the IMS LIP.

### 2.2.5 Internet2 eduPerson

In February 2001the joint Internet2(R) and EDUCAUSE working group announced the release of the ‘eduPerson’ specification for services that provide seamless access to network-accessible information regardless of where or how the original information is stored. The eduPerson specification provides a set of standard higher-education attributes for an enterprise directory, which facilitate inter-institutional access to applications and resources across the higher education community. The EDUCAUSE/Internet2 eduPerson task force has the mission of defining a Lightweight Directory Access Protocol (LDAP) object class that includes widely-used person attributes in higher education. An example of how to use the IMS LIP to exchange the eduPerson information is shown in Section 6.

### 2.2.6 HR-XML Consortium Specifications

The HR-XML Consortium is an independent, non-profit association dedicated to the development and promotion of a standard suite of XML specifications to enable e-commerce and the automation of human resources-related data exchanges. The mission of the HR-XML Consortium is to develop and publish open data exchange standards based upon XML. Some of the Consortium’s initial targets for standardization activities include recruiting, staffing, compensation and benefits. The Consortium’s Recruiting and Staffing workgroup is working on a first version of Staffing Exchange Protocol (SEP), an XML-based messaging framework that supports dynamic, real-time staffing transactions over the Web. Transactions supported by SEP include the posting of job opportunities to job boards and other recruiting venues and the return of resumes matching those postings. The protocol also supports the up-dating and recall of job postings, the supplying of contact information for a job candidate where only partial information was initially supplied, employer feedback to job boards on positions that have been filled, and the update and recall of resumes by job seekers. The Consortium’s Compensation and Benefits Workgroup has begun work on an XML framework for communicating employee benefit enrollment information between employers and insurance carriers, managed care organizations, and third party administrators. The workgroup also is working to deploy a demonstration of how standardized XML can streamline the transfer of Defined Contribution and Defined Benefit (DC/DB) data between a plan sponsor, such as an employer, and a plan provider.

## 2.3 Related Activities

### 2.3.1 ISO/IEC JTC1/SC36 Learning Technology

As of 10th November 1999, the ISO/IEC Joint Technical Committee 1 meeting in Seoul agreed resolution 6, which brought into existence Sub-Committee 36 - Learning Technology. The international secretariat for SC36 is provided by the US National Body, the American National Standards Institute (ANSI). ISO/IEC JTC1/SC36 is intended to address standardisation in the area of information technologies that support automation for learners, learning institutions, and learning resources. It is the intention that SC36 shall not create standards or technical reports that define educational standards, cultural conventions, learning objectives, or specific learning content. Their activity in the field of question and test has yet to be defined. The UK delegation to ISO has offered to undertake preliminary work on learning profiles on behalf of ISO.

### 2.3.2 Advanced Distributed Learning (ADL) Initiative

ADL is a US military programme started by the White House in 1997 that aims to advance the use of state-of-the-art on-line training amongst the countries defence forces. There is some collaboration with experts in military training applications from other NATO countries. ADL is very focused on content for particular areas of training. It also has the Shareable Courseware Object Reference Model (SCORM v1.0) as a working document to encourage discussion and input on the emerging standards. No separate Learner Information specification is underway.

### 2.3.3 Aviation Industry CBT Committee (AICC)

The Aviation Industry CBT Committee is a membership-based international forum that develops recommendations on interoperable learning technology, principally for the commercial aviation and related industries. As such its members include both plane and equipment manufacturers, carriers, software and multimedia vendors and a growing number of interested parties not directly engaged in the sector, but nevertheless interested in the work being done there. A sub-group of the AICC have been working with the ADL and other organisation from the IEEE LTSC.

### 2.3.4 EU ACTS Gestalt Project

The EU ACTS Project GESTALT (Getting Educational Systems Talking Across Leading-edge Technologies) addressed the issues of integrating a number of technologies able to support the planned integration. CORBA and DCOM were used to provide the distributed platform support required by this application. A meta-data format servicing the requirements of the application was specified, drawing on the work of bodies such as the IMS Project and the IEEE LTSC. In addition, W3C XML meta-data extensions, such as SMIL, were explored for providing object synchronisation. The Gestalt project was completed in March, 2000.

### 2.3.5 CEN/ISSS

CEN/ISSS, in co-operation with the European Commission’s DG III & DG XIII has set up a working group to address European requirements for Educational Technology. This working group aims to achieve a consensus view in this area through the following actions:

- A requirements gathering stage to discover the precise needs of European developers and users;

- Consensus within a working group established under the TEISS (Telematics European Industry Standardisation Support) framework on the standardisation process for educational technology;

- Coherent developments within metadata under the CEN/ISSS workshop process after this stage;

- Coherent development of standards for interoperability which allow learning resources to work together and seamlessly with learning management systems;

- Publication and transmission of recommendations by the work group to publishers, suppliers of hardware and services, telecommunications operators, industry bodies generally, standardisation bodies, the European Commission and international standards bodies.

## 2.4 IMS Specification Development Process

The development life-cycle for an IMS specification has been established as:

- Month 1 – set-up of the team including identification of the team leads (for LIP this is Robby Robson, Saba, and Frank Tansy, IMS), editor (for LIP this is Colin Smythe, Dunelm Services Ltd) and key collaborating groups and organisations;

- Month 2 – Team and scope/requirements development;

- Month 3 – Initial internal team documents developed;

- Month 4 – Base document development and vote. Approval of the Base Documents by the Technical Board;

- Month 5 – Document improvement. Open issues are identified and solutions developed. Companies are encouraged to develop code against the base documents;

- Month 6 – Further document improvement and feedback from organisations involved in implementations;

- Month 7 – Completion of the Public Draft Specification and approval by the IMS Technical Board;

- Months 8 & 9 – Accept feedback from organisations working to the Public Draft Specification. Resolve any issues raised;

- Month 10 – Completion of the Final Specification and approval by the IMS Technical Board. This is the combination of the Public Draft Specification plus resolutions due to experience gained in working with it.

A draft specification is developed within the IMS developer and user community, which currently includes more than 200 organisations from around the world. In a number of cases, one of these organisations represents many other organisations, such as the Australian Government’s DETYA organisation, which provides access to the IMS community for all institutions of learning in Australia.

The term ‘Base Document’ is used for draft specifications that have reached a relatively high level of stability based on input from the team and the Technical Board. Base documents represent the stage in the specification process of final development and refinement. It is base documents that are presented in their final forms to the IMS Technical Board for vote. If approved, the document becomes a ‘Public Draft Specification’ and is listed as such on the IMS public web site. If not approved, the team works through whatever adjustments and recommendations the Technical Board provides, and then resubmits the document. After three months the Public Draft Specification should be adopted as a ‘Final Specification’.

After a final specification is released, the team develops the next scope document for the subsequent work. New requirements and features dropped from the previous specification constitute the scope of the next effort.

# 3. Overall Data Model

## 3.1 Information Model

The data model for the LIP is shown in Figure 3.1 (this is the same as that described in the LIP Information Model, [LIP, 01b]).

Figure 3.1 The IMS LIP data model.

The objects in this model and their key behaviours are:

learnerinformation The data structure responsible for encapsulating the eleven core learner information classes. The control information describing the learner information as a whole is contained within the ‘contentype’ class;

identification The learner information that contains all of the data for a specific individual or organisation. This includes data such as: names, addresses, contact information, demographics and agent;

accessibility The learner information that consists of the cognitive, technical and physical preferences for the learner, their language capabilities, disability and eligibilities;

goal This learner information consists of the description of the personal objectives and aspirations. These descriptions may also include information for monitoring the progress in achieving those goals. A goal can be defined in terms of sub-goals;

qcl This learner information consists of the qualifications, certificationss and licenses awarded to the learner i.e. the formally recognised products of their learning and work history. This includes information on the awarding body and may also include electronic copies of the actual documents;

activity The learner information that consists of the education/training, work and service (military, community, voluntary, etc.) record and products (excluding formal awards). This information may include the descriptions of the courses undertaken and the records of the corresponding evaluation;

transcript The summary record of the academic performance of an individual with respect to a particular institution. The transcript is normally supplied by the body responsible for evaluating the performance of the individual;

competency This learner information consists of the descriptions of the skills the learner has acquired. These skills may be associated with some formal or informal training or work history (described in the ‘activity’) and formal awards (described in the ‘qcl’). The corresponding level of competency may also be defined;

interest The learner information that consists of descriptions of the hobbies and other recreational activities. These activities may have formal awards (as described in the associated ‘qcl’). Electronic versions of the products of these interests may also be contained;

affiliation This learner information is used to store the descriptions of the affiliations associated with the learner e.g. professional affiliations. A learner’s membership of the relevant class, cohorts, groups, etc. undertaken when being educated, trained, etc. should be supported using the IMS Enterprise specification;

securitykey This learner information is used to store the descriptions of the passwords, certificates, PINs and authentication keys. These keys are used for transactions with the learner;

relationship The container for the definition of the relations between the other core data structures e.g. ‘qcl’s and the awarding organisation. This enables the construction of complex relationships between the core data structures;

contentype The container for the control information that is used to describe the learner information. This information consists of referential, temporal and privacy information and is applied to each of the ‘atomic’ parts of the learner information structure;

referential The referential information is used to uniquely identify the learner information record as a whole and the individual data components within that record. These enable each piece of information to be identified. The actual identification system is outside the scope of this specification;

temporal This information is used to describe any time-based dependencies of the data. This includes information such as the date of creation, time-stamp and expiry date of the learner information. The date/time descriptions are expected to conform to the ISO8601 standard;

privacy All of the data relevant to the privacy, authenticity and integrity of the learner information is contained within this structure. The actual privacy etc. mechanism and architectures used to support the learner information are outside of the scope of the specification but they interact with the learner information through these structures.

## 3.2 XML Schema Tree[2]

### 3.2.1 Core XML Schema Tree

The core XML schema tree is shown in Figure 3.2.

Figure 3.2 The core XML schema tree.

### 3.2.2 <identification> XML Schema Tree

The identification XML schema tree is shown in Figure 3.3.

Figure 3.3 The <identification> XML schema tree.

### 3.2.3 <goal> XML Schema Tree

The goal XML schema tree is shown in Figure 3.4.

Figure 3.4 The <goal> XML schema tree.

### 3.2.4 <qcl> XML Schema Tree

The qcl XML schema tree is shown in Figure 3.5.

Figure 3.5 The <qcl> XML schema tree.

### 3.2.5 <accessibility> XML Schema Tree

The accessibility XML schema tree is shown in Figure 3.6.

Figure 3.6 The <accessibility> XML schema tree.

### 3.2.6 <activity> XML Schema Tree

The activity XML schema tree is shown in Figure 3.7.

Figure 3.7 The <activity> XML schema tree.

### 3.2.7 <competency> XML Schema Tree

The competency XML schema tree is shown in Figure 3.8.

Figure 3.8 The <competency> XML schema tree.

### 3.2.8 <interest> XML Schema Tree

The interest XML schema tree is shown in Figure 3.9.

Figure 3.9 The <interest> XML schema tree.

### 3.2.9 <transcript> XML Schema Tree

The transcript XML schema tree is shown in Figure 3.10.

Figure 3.10 The <transcript> XML schema tree.

### 3.2.10 <affiliation> XML Schema Tree

The affiliation XML schema tree is shown in Figure 3.11.

Figure 3.11 The <affiliation> XML schema tree.

### 3.2.11 <securitykey> XML Schema Tree

The securitykey XML schema tree is shown in Figure 3.12.

Figure 3.12 The <securitykey> XML schema tree.

### 3.2.12 <relationship> XML Schema Tree

The relationship XML schema tree is shown in Figure 3.13.

Figure 3.13 The <relationship> XML schema tree.

# 4. Basic Example LIP Instances

The basic examples are arranged according to the eleven core data structures. The examples supplied are:

- Accessibility

  – Language: the definition of the language proficiencies for a learner

  – Preference: the definition of a learner’s cognitive, physical and technology preferences;

- Activity

  – Learning activity reference: an external reference mechanism to the learning materials

  – Definition: the definition of the materials studied

  – Product: the materials developed by the learner themselves

  – Testimonial: statements attesting to the capabilities of the learner

  – Evaluation: the results of the evaluations undertaken;

- Affiliation – the professional affiliations and associated roles of the learner;

- Competency the competencies of the learner;

- Goal – the goals and sub-goals of the learner

- Identification

  – Formatted Name: the formatted names for a learner

  – Name: the names for a learner

  – Address: the addresses for a learner

  – Contactinfo: the electronic-based contact information for the a learner

  – Demographics: the demographics information about the learner

  – Agent: the representatives permitted to act on behalf of the learner;

- Interest – the hobbies and recreational interests of the learner;

- Qcl – description of the qualification, certifications and licences for a learner;

- Relationship – the set of relationships that are to be defined between the learner and their identification, accessibility, qualifications, competencies, goals, activities, interests, transcripts, securitykeys and affiliations;

- Securitykey – the security-oriented information to be used with respect to the learner;

- Transcript – the transcripts that summarise the performance of the learner.

## 4.1 Accessibility Examples

### 4.1.1 Accessibility Language Examples

This example defines the ‘German’ language abilities of the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     <learnerinformation>
        <comment>An example of LIP Accessibility information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_1001</id>
               </sourcedid>
            </referential>
        </contentype>
        <accessibility>
            <contentype>
               <referential>
                   <indexid>accessibility_01</indexid>
               </referential>
            </contentype>
            <language>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>German</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>language_01</indexid>
                   </referential>
               </contentype>
               <proficiency profmode="OralSpeak">Excellent</proficiency>
               <proficiency profmode="OralComp">Excellent</proficiency>
               <proficiency profmode="Read">Good</proficiency>
               <proficiency profmode="Write">Poor</proficiency>
            </language>
        </accessibility>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_lang_001/accs_lang_001.xml.

The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7). This must be used for all further references to this learner;

- The language is identified as ‘German’ in line 20;

- The language oral, reading and writing proficiencies are defined in lines 27-30 respectively.

The next stage is to create a second set of language proficiencies for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     <learnerinformation>
        <comment>An example of LIP Accessibility information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_1001</id>
               </sourcedid>
            </referential>
        </contentype>
        <accessibility>
            <contentype>
               <referential>
                   <indexid>accessibility_01</indexid>
               </referential>
            </contentype>
            <language>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Spanish</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>language_02</indexid>
                   </referential>
               </contentype>
               <proficiency profmode="OralSpeak">Poor</proficiency>
               <proficiency profmode="OralComp">Poor</proficiency>
               <proficiency profmode="Read">Good</proficiency>
               <proficiency profmode="Write">Good</proficiency>
            </language>
        </accessibility>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_lang_002/accs_lang_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7) – as per the previous language example;

- The same accessibility record is denoted by the usage of the same indexid i.e. ‘accessibility_01’ (line 14 in both examples). The fact that a new language is being supplied is denoted by the fact that a new language indexid is used i.e. ‘language_02’ (cf. line 21 in both examples);

- The language oral, reading and writing proficiencies are defined in lines 27-30 respectively.

### 4.1.2 Accessibility Preference Examples

This example creates the input technology preferences of the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     <learnerinformation>
        <comment>An example of LIP Accessibility information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_1001</id>
               </sourcedid>
            </referential>
        </contentype>
        <accessibility>
            <contentype>
               <referential>
                   <indexid>accessibility_01</indexid>
               </referential>
            </contentype>
            <preference>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>InputTech</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>preference_01</indexid>
                   </referential>
               </contentype>
               <prefcode>Large Font Display Devices</prefcode>
            </preference>
        </accessibility>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_pref_001/accs_pref_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7). This must be used for all further references to this learner;

- The preference is defined as ‘Input Technology’ in line 20;

- The actual preference entry is given in line 27.

The next stage is to create a second preference for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     <learnerinformation>
        <comment>An example of LIP Accessibility information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_1001</id>
               </sourcedid>
            </referential>
        </contentype>
        <accessibility>
            <contentype>
               <referential>
                   <indexid>accessibility_01</indexid>
               </referential>
            </contentype>
            <preference>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Cognitive</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>preference_02</indexid>
                   </referential>
               </contentype>
               <prefcode>Exploratory</prefcode>
            </preference>
        </accessibility>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_pref_001/accs_pref_002.xml.

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7) – as per the previous language example;

- The same accessibility record is denoted by the usage of the same indexid i.e. ‘accessibility_01’ (line 14 in both examples). The fact that a new preference is being supplied is denoted by the fact that a new preference indexid is used i.e. ‘preference_02’ (cf. line 21 in both examples);

- The new preference (a cognitive type) is stored in line 27.

## 4.2 Activity Examples

### 4.2.1 Activity Learningactivetyref Examples

This example creates an activity containing a learninactivityref record for the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Award</tyvalue>
               </typename>
               <datetime>1980:7</datetime>
            </date>
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>CreditNumber</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>10</fielddata>
               </unitsfield>
            </units>
            <learningactivityref>
               <text>HNC in Mathematics</text>
            </learningactivityref>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_lref_001/actv_lref_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of activity is defined in line 14;

- The content of the record is based upon the date of the activity (lines 21-27), the credits assigned to the activity (lines 28-37) and the external reference to the learning activity (lines 38-40).

The next stage is to create a second learningactivityref record for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_2</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Award</tyvalue>
               </typename>
               <datetime>1988:7</datetime>
            </date>
            <learningactivityref>
               <text>HND in Electronics</text>
            </learningactivityref>
        </activity>
     </learnerinformation

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_lref_002/actv_lref_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – as per the previous learningactiviyref example;

- The type of activity is defined in line 14;

- The content of the record is based upon the date of the activity (lines 21-27) and the external reference to the learning activity (lines 28-30).

### 4.2.2 Activity Definition Examples

This example creates an activity containing a course definition record for the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     72
     73
     74
     75
     76
     77
     78
     79
     80
     81
     82
     83
     84
     85
     86
     87
     88
     89
     90
     91
     92
     93
     94
     95
     96
     97
     98
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <definition>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Course</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>DegreeCourse</indexid>
                   </referential>
               </contentype>
               <definition>
                  <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Curriculum</tyvalue>
                   </typename>
                   <contentype>
                      <referential>
                          <indexid>Year1</indexid>
                      </referential>
                   </contentype>
                   <definition>
                      <typename>
                          <tysource sourcetype="imsdefault"/>
                          <tyvalue>Module</tyvalue>
                      </typename>
                      <contentype>
                          <referential>
                             <indexid>Electronics_101</indexid>
                          </referential>
                      </contentype>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture1</tyvalue>
                             </typename>
                          </fieldlabel>
                          <fielddata>BooleanLogic</fielddata>
                      </definitionfield>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture2</tyvalue>
                             </typename>
                          </fieldlabel>
                          <fielddata>Transistors</fielddata>
                      </definitionfield>
                   </definition>
                   <definition>
                      <typename>
                          <tysource sourcetype="imsdefault"/>
                          <tyvalue>Module</tyvalue>
                      </typename>
                      <contentype>
                          <referential>
                             <indexid>Maths_101</indexid>
                          </referential>
                      </contentype>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture1</tyvalue>
                             </typename>
                          </fieldlabel>
                          <fielddata>BooleanLogic1</fielddata>
                      </definitionfield>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture2</tyvalue>
                             </typename>
                          </fieldlabel>
                          <fielddata>BooleanLogic2</fielddata>
                      </definitionfield>
                   </definition>
               </definition>
            </definition>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_defn_001/actv_defn_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of activity is defined in line 14;

- The full definition is given in lines 21-96. This is a hierarchical structure for two modules being taught in the first year of a course. The course identification is given in lines 26-30. The year one curriculum is given in lines 31-95 and consists of two modules – electronics 101 (lines 41-67) and maths 101 (lines 68-94). For the elctronics module there a two lectures – Lecture 1 in Boolean Logic (lines 51-58) and Lecture 2 in Transistors (lines 59-66). Similarly for maths 101 there are two modules – Lecture 1 in Boolean Logic (lines 78-85) and Lecture 2 in Boolean Logic (lines 86-93).

The next stage is to create a second course definition for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <definition>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Course</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>DegreeCourse</indexid>
                   </referential>
               </contentype>
               <definition>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Curriculum</tyvalue>
                   </typename>
                   <contentype>
                      <referential>
                          <indexid>Year2</indexid>
                      </referential>
                      </contentype>
                   <definition>
                      <typename>
                          <tysource sourcetype="imsdefault"/>
                          <tyvalue>Module</tyvalue>
                      </typename>
                      <contentype>
                          <referential>
                             <indexid>Maths_201</indexid>
                          </referential>
                      </contentype>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture1</tyvalue>
                             </typename>
                         </fieldlabel>
                          <fielddata>FourierTransform1</fielddata>
                      </definitionfield>
                      <definitionfield>
                          <fieldlabel>
                             <typename>
                                <tyvalue>Lecture2</tyvalue>
                             </typename>
                          </fieldlabel>
                          <fielddata>FourierTransform2</fielddata>
                      </definitionfield>
                   </definition>
               </definition>
            </definition>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_defn_002/actv_defn_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – as per the previius definition example;

- The type of activity is defined in line 14;

- The year 2 curriculum information is being added to the previous year 1 information. This material is defined in lines 31-69. This consists of a single module (lines 41-68) which itself consists of two lectures (lines 51-58 and 59-66).

### 4.2.3 Activity Product Examples

This example creates an activity containing a product record for the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Create</tyvalue>
               </typename>
               <datetime>1980:7</datetime>
            </date>
            <product>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Coursework</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_product_01</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>Thesis</short>
                   <full>
                      <media mediamode="Text" mimetype="text/word" contentreftype="uri">
                          myfile/thesis.doc
                      </media>
                   </full>
               </description>
            </product>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_prod_001/actv_prod_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7). This should be used for other related transactions;

- The type of activity is defined in line 14;

- The product record date of creation is recorded (lines 21-27). The product record itself is given in lines 28-46. The type of product is defined (line 31) and it is given an index identifier (lines 33-37). The product itself, a copy of the learner’s thesis is given in lines 38-45.

The next stage is to create a second product record for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Create</tyvalue>
               </typename>
               <datetime>1980:7</datetime>
            </date>
            <product>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Exam</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_product_02</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>Archived CBT Exam Paper</short>
                   <full>
                      <media mediamode="Text" mimetype="text/word" contentreftype="uri">
                          assess/exam1.cbt
                      </media>
                   </full>
               </description>
            </product>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_prod_002/actv_prod_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – as per the previous definition example;

- The type of activity is defined in line 14;

- The product record date of creation is recorded (lines 21-27). The product record itself is given in lines 28-46. The type of product is defined (line 31) and it is given an index identifier (lines 33-37). The product itself, a copy of the larchived CBT exam is given in lines 38-45.

### 4.2.4 Activity Testimonial Examples

This example creates an activity containing a testimonial record for the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Award</tyvalue>
               </typename>
               <datetime>1980:7</datetime>
            </date>
            <testimonial>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Academic</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_testimonial_01</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>Tutors reference</short>
                   <full>
                      <media mediamode="Text" mimetype="text/word" contentreftype="uri">
                          tutor/ref.doc
                      </media>
                   </full>
               </description>
            </testimonial>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_test_001/actv_test_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7). This should be used for other related transactions;

- The type of activity is defined in line 14;

- The testimonial record date of creation is recorded (lines 21-27). The testimonial record itself is given in lines 28-46. The type of testimonial is defined (line 31) and it is given an index identifier (lines 33-37). The testimonial itself, a copy of the tutor’s reference is given in lines 38-45.

The next stage is to create a second testimonial record for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Create</tyvalue>
               </typename>
               <datetime>1980:7</datetime>
            </date>
            <testimonial>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Academic</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_testimonial_02</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>Head of Departments reference</short>
                   <full>
                      <media mediamode="Text" mimetype="text/word" contentreftype="Base-64">
                          This is an outstanding student.
                      </media>
                   </full>
               </description>
            </testimonial>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_test_002/actv_test_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – this is the same as for the previous testimonial example;

- The type of activity is defined in line 14;

- The testimonial record date of creation is recorded (lines 21-27). The testimonial record itself is given in lines 28-46. The type of testimonial is defined (line 31) and it is given an index identifier (lines 33-37). The testimonial itself, a copy of the Head of Department’s reference is given in lines 38-46 (this is embedded in the XML instance itself).

### 4.2.5 Activity Evaluation Examples

This example creates an activity containing an evaluation record for the learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>CreditNumber</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>20</fielddata>
               </unitsfield>
            </units>
            <evaluation>
               <contentype>
                   <referential>
                      <sourcedid>
                          <source>ExamBoard</source>
                          <id>12345</id>
                      </sourcedid>
                   </referential>
               </contentype>
               <result>
                   <interpretscore>
                      <fieldlabel>
                          <typename>
                             <tyvalue>MinimumScore</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>0</fielddata>
                   </interpretscore>
                   <interpretscore>
                      <fieldlabel>
                          <typename>
                             <tyvalue>MaximumScore</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>100</fielddata>
                   </interpretscore>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Score</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>30</fielddata>
                   </score>
               </result>
            </evaluation>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1Examples/Valid/Basic/actv_eval_001/actv_eval_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7). This should be used for other related transactions;

- The type of activity is defined in line 14;

- The evaluation record includes the number of units assigned to the activity (lines 21-30), the evaluation identifier (lines 32-39), and the actual results (lines 40-65). The results consist of two sets of interpretive information (lines 41-48 and 49-56) and the actual score itself (lines 57-64).

The next stage is to create a second evaluation record for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     <learnerinformation>
        <comment>An example of LIP Activity information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>2001</id>
               </sourcedid>
            </referential>
        </contentype>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Education</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_1</indexid>
               </referential>
            </contentype>
            <evaluation>
               <contentype>
                   <referential>
                      <sourcedid>
                          <source>ExamBoard</source>
                          <id>12346</id>
                      </sourcedid>
                   </referential>
               </contentype>
               <result>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Score</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>65</fielddata>
                   </score>
               </result>
            </evaluation>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_eval_002/actv_eval_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – the same as for the previous evaluation example;

- The type of activity is defined in line 14;

- The evaluation record (lines 21-40) includes the evaluation identifier (lines 22-29), and the actual results (lines 30-39). The results consist of the actual score itself (lines 31-38).

## 4.3 Affiliation Examples

This example creates the professional affiliation for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     <learnerinformation>
        <comment>An example of LIP Affiliation information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>3001</id>
               </sourcedid>
            </referential>
        </contentype>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_01</indexid>
               </referential>
            </contentype>
            <classification>Member</classification>
            <affiliationid>2457923A</affiliationid>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Professional</tyvalue>
               </typename>
               <description>
                   <short>Institute of Electronic and Electrical Engineers</short>
               </description>
            </organization>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Join</tyvalue>
               </typename>
               <datetime>1992</datetime>
            </date>
            <status>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Active</tyvalue>
               </typename>
            </status>
            <description>
               <short>All fees paid</short>
            </description>
        </affiliation>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/affl_002/affl_002.xml.

The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_3001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of affiliation is defined as professional (line 14);

- The membership classification, membership number and the name of organisation is given in lines 21, 22 and 23-31 respectively;

- The date of initial membership and current status is given in lines 32-38 and 39-44 respectively.

The next stage is to to add the learners role in the affiliation for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     <learnerinformation>
        <comment>An example of LIP Affiliation information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>3001</id>
               </sourcedid>
            </referential>
        </contentype>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_01</indexid>
               </referential>
            </contentype>
            <role>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Officer</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>affiliation_role_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1994:04:01</datetime>
               </date>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Finish</tyvalue>
                   </typename>
                   <datetime>1995:03:31</datetime>
               </date>
               <description>
                   <short>IEEE Local Chapter Treasurer</short>
               </description>
            </role>
        </affiliation>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/affl_003/affl_003.xml.

The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_3001’ (lines 6 and 7) – as per the previous affiliation eample;

- The same affiliation identifier is used (line 18) and so this implies this transaction would be an update transaction;

- The role information is given in lines 21-48. The role itself is identified in line 24 and the associated start and finish dates in lines 31-44 and 38-44 respectively. A short description is given in lines 45-47.

## 4.4 Competency Examples

This example creates a new competency record for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     <learnerinformation>
        <comment>An example of LIP Competency information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>4001</id>
               </sourcedid>
            </referential>
        </contentype>
        <competency>
            <contentype>
               <referential>
                   <indexid>competency_01</indexid>
               </referential>
            </contentype>
            <exrefrecord>
               <recformat uri="compformats/vocabulary.doc"/>
               <recdata uri="learner1/competency.doc"/>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Award</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
            </exrefrecord>
            <description>
               <short>IT Competencies</short>
            </description>
        </competency>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/comp_002/comp_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_4001’ (lines 6 and 7). This must be used for all further references to this learner;

- The actual competency is defined in terms of its format (line 18) and the external reference to the material itself (line 19). The date of award is also stored (lines 20-26).

This next stage is to create a competency record for a different learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     <learnerinformation>
        <comment>An example of LIP Competency information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>4002</id>
               </sourcedid>
            </referential>
        </contentype>
        <competency>
            <contentype>
               <referential>
                   <indexid>competency_01</indexid>
               </referential>
            </contentype>
            <exrefrecord>
               <recformat uri="compformats/vocabulary.doc"/>
               <recdata uri="learner2/competency.doc"/>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Award</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
            </exrefrecord>
            <description>
               <short>IT Competencies</short>
            </description>
        </competency>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/comp_003/comp_003.xml. The key features of this example are:

- The core record for this new learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_4002’ (lines 6 and 7). This must be used for all further references to this learner;

- The actual competency is defined in terms of its format (line 18) and the external reference to the material itself (line 19). The date of award is also stored (lines 20-26).

## 4.5 Goal Examples

This example creates the record of a goal for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     <learnerinformation>
        <comment>A basic example of a Goal.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_5001</id>
               </sourcedid>
            </referential>
        </contentype>
        <goal>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>goal_01</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>2000:11:06</datetime>
            </date>
            <priority>Primary Objective</priority>
            <status>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Active</tyvalue>
               </typename>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Effective</tyvalue>
                   </typename>
                   <datetime>2000:11:06</datetime>
               </date>
            </status>
            <description>
               <short>Career Plan</short>
               <full>
                   <media mediamode="Text" mimetype="text/word" contentreftype="uri">
                      learner1/careerplan.doc
                   </media>
               </full>
            </description>
        </goal>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/goal_002/goal_002.xml.

The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_5001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of goal is defined in line 14 and the index for the goal is given in line 18;

- The priority of the goal is defined in line 28 and the status by lines 29 to 41. The status is defined as ‘Active’ and the date of entry of the status is given in line 32;

- The actual goal is described in lines 42 to 49 with the actual reference to the text file containing the description given in line 46. The file name includes the directory (‘learner1’) - this approach is used to ensure that packaging of multiple instances using the IMS Content Packaging specification can be achieved.

The next stage is to add a sub-goal to the goal created in the previous example. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     <learnerinformation>
        <comment>A basic example of adding a sub-goal.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_5001</id>
               </sourcedid>
            </referential>
        </contentype>
        <goal>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>goal_01</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Update</tyvalue>
               </typename>
               <datetime>2000:11:07</datetime>
            </date>
            <goal>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>goal_01_subgoal_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>2000:11:07</datetime>
               </date>
               <description>
                   <short>Sub-goal for the goal that is the primary objective</short>
                   <full>
                      <media mediamode="Text" mimetype="text/word" contentreftype="uri">
                          learner1/subgoal1.doc
                      </media>
                   </full>
               </description>
            </goal>
        </goal>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/goal_003/goal_003.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_5001’ (lines 6 and 7) - this is as per the previous ‘goal’ example. The same goal identifier is used as per line 19;

- The sub-goal itself is defined in lines 29 to 54. This sub-goal has its own index number as shown in line 36. The actual sub-goal text is stored in an external file as defined in line 49 i.e. the file “learner1/subgoal1.doc”;

- The transaction instructions are not contained in the XML instance - this is outside the scope of the IMS LIP specification.

## 4.6 Identification Examples

### 4.6.1 Identification Formatted Name Examples

This example creates the formatted name record for: Frederick Williams. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     <learnerinformation>
        <comment>A basic example of creating a formatted name.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>ims_lipexample_v1p0</source>
                   <id>basic_6001</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <formname>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Preferred</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>formname_01</indexid>
                   </referential>
               </contentype>
               <text>Frederick Williams</text>
            </formname>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_fnme_001/iden_fnme_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘ims_lipexample_v1p0:basic_6001’ (lines 6 and 7). This must be used for all further references to this learner;

- The formatted name is defined as the ‘Preferred name” (line 20);

- The formatted name itself is given in line 27.

The next stage is to create a second formatted name record for ‘Frederick Williams that will be used as his contact name. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     <learnerinformation>
        <comment>A basic example of creating a formatted name.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>ims_lipexample_v1p0</source>
                   <id>basic_6001</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <formname>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Contact</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>formname_02</indexid>
                   </referential>
               </contentype>
               <text>Professor Frederick Calland Williams</text>
            </formname>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_fnme_002/iden_fnme_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous formatted name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The new formatted name entry is identified by the fact that it has a new <indexid>. In this example the identifier is ‘formname_02’ (line 24) whereas for the previous example it was ‘formname_01” (line 24);

- The formatted name is given in line 27 and the nature of the formatted name i.e. it is the ‘Contact’ name, is defined in line 20.

### 4.6.2 Identification Name Examples

This example creates the name record for: Alan Turing. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     <learnerinformation>
        <comment>A basic example of creating a compound name.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>ims_lipexample_v1p0</source>
                   <id>basic_6002</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <name>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Preferred</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>name_01</indexid>
                   </referential>
               </contentype>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>First</tyvalue>
                   </typename>
                   <text>Alan</text>
               </partname>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Last</tyvalue>
                   </typename>
                  <text>Turing</text>
               </partname>
            </name>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_name_001/iden_name_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘ims_lipexample_v1p0:basic_6002’ (lines 6 and 7). This must be used for all further references to this learner;

- The name is defined as the ‘Preferred name” (line 20);

- The name parts themselves are given in lines 32 and 39. The corresponding part types are defined in lines 30 and 37 respectively.

The next stage is to add a name part, middle name, to this learner’s name. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     <learnerinformation>
        <comment>A basic example of creating a compound name.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>ims_lipexample_v1p0</source>
                   <id>basic_1002</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <name>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Preferred</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>name_01</indexid>
                   </referential>
               </contentype>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Middle</tyvalue>
                   </typename>
                   <text>Mathison</text>
               </partname>
            </name>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_name_002/iden_name_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous formatted name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The same name entry is identified by the fact that it has the same <indexid> i.e. ‘name_01’. The mechanism by which the nature of the transaction is passed between the systems i.e. stating the new information is an update to current data, is outside the scope of this specification;

- The new name part is given in line 32 and the nature of the formatted name i.e. it is the ‘Middle’ name, is defined in line 30.

### 4.6.3 Identification Address Examples

This example creates the address for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     <learnerinformation>
        <comment>A basic example of an address in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6003</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <address>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Private</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>address_01</indexid>
                   </referential>
               </contentype>
               <street>
                   <nonfieldedstreetaddress>Towerview Apartment 3A, 34 Oxford St
                   </nonfieldedstreetaddress>
                   <complex>Towerview</complex>
                   <streetnumber>34</streetnumber>
                   <streetname>Oxford</streetname>
                   <streetype>Street</streetype>
                   <aptnumber>3</aptnumber>
                   <aptnumsuffix>A</aptnumsuffix>
               </street>
               <locality>West-end</locality>
               <city>London</city>
               <country>UK</country>
               <postcode>SE23 2RR</postcode>
               <timezone>GMT</timezone>
               <geo>
                   <lat>57.01.49N</lat>
                   <lon>00.00.00E</lon>
               </geo>
            </address>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_addr_001/iden_addr_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘ims_lipexample_v1p0:basic_6003’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of the address is given in line 20 i.e. a ‘Private’ address;

- The address is given in lines 27 to 45 based upon the street information (lines 27 to 36), the locality (line 37), the city (line 38), the country (line 39), the postcode (line 40), the time-zone (line 41) and the geographic location (lines 42 to 45);

- The detailed street address is shown in two forms, the non-fielded form (lines 28 and 29) and the compound form (lines 30 to 35).

This next stage is to add a second address to the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     <learnerinformation>
        <comment>A basic example of an address in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6003</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <address>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>address_02</indexid>
                   </referential>
               </contentype>
               <pobox>PO236</pobox>
               <city>London</city>
               <country>UK</country>
               <postcode>SW3 4RQQ</postcode>
            </address>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_addr_002/iden_addr_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous formatted name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The new address is identified by the index shown in line 24 i.e. this address identifier must not have been used previously;

- The address itself is given in lines 27-30.

### 4.6.4 Identification Contactinfo Examples

This example creates the contact information for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     <learnerinformation>
        <comment>A basic example of contact information in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6004</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contactinfo_01</indexid>
                   </referential>
               </contentype>
               <telephone>
                   <countrycode>44</countrycode>
                   <areacode>020</areacode>
                   <indnumber>6472239</indnumber>
               </telephone>
            </contactinfo>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contactinfo_02</indexid>
                   </referential>
               </contentype>
               <facsimile>
                   <countrycode>44</countrycode>
                   <areacode>020</areacode>
                   <indnumber>6472238</indnumber>
               </facsimile>
            </contactinfo>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_cinf_001/iden_cinf_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_6004’ (lines 6 and 7). This must be used for all further references to this learner;

- Two types of contact information have been supplied i.e. telephone (lines 27 to 31) and facsimile (lines 43 to 47). The types of contact information are identified in lines 20 and 36 respectively (‘Work’) and the identifiers are given in lines 24 and 40 respectively;

- In each case the telephone and facsimile numbers consist of country code, area code and individual number.

This next stage is to add more contact information to the same learner i.e. an email address. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     <learnerinformation>
        <comment>A basic example of contact information in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6004</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contactinfo_03</indexid>
                   </referential>
               </contentype>
               <email>enquiries@work.com</email>
            </contactinfo>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_cinf_002/iden_cinf_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous contact information name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The new email address is given in line 27. This new information has its own identifier, as shown in line 24.

### 4.6.5 Identification Demographics Examples

This example creates the demographics information for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     <learnerinformation>
        <comment>A basic example of demographics in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6005</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <demographics>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Adult</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>demographics_01</indexid>
                   </referential>
               </contentype>
               <gender gender="M"/>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Birth</tyvalue>
                   </typename>
                   <datetime>1901:04:01</datetime>
               </date>
               <placeofbirth>Boston, Massacheusettes</placeofbirth>
               <uid>09234789A</uid>
            </demographics>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_demg_001/iden_demo_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_6005’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of demographic record is define in line 20. The structure identifier is given in line 24;

- The actual demographics information includes the gender (line 27), date of birth (lines 28-34), place of birth (line 35) a a user identifier (line 36).

This next stage is to add more demographics information for the same learner i.e. a photograph. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     <learnerinformation>
        <comment>A basic example of demographics in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                  <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6005</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <demographics>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Adult</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>demographics_01</indexid>
                   </referential>
               </contentype>
               <representation>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Photo</tyvalue>
                   </typename>
                   <date>
                      <typename>
                          <tysource sourcetype="imsdefault"/>
                          <tyvalue>Create</tyvalue>
                      </typename>
                      <datetime>1940</datetime>
                   </date>
                   <description>
                      <full>
                          <media mediamode="Image" mimetype="image/gif" contentreftype="uri">
                             photo/photo.gif
                          </media>
                      </full>
                   </description>
               </representation>
            </demographics>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_demg_002/iden_demo_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous contact information name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The new demographics information is added, a photograph. The type of representation is defined (line 30), the date of creation (lines 32-38) and the external reference to the actual photograph (lines 28-31). The actual media reference is given in lines 39-45.

### 4.6.6 Identification Agent Examples

This example creates the agent information for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     365
     37
     38
     39
     <learnerinformation>
        <comment>A basic example of agent in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6006</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <agent>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Sponsor</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>agent_01</indexid>
                   </referential>
               </contentype>
               <agentid>SYLEA98_01137</agentid>
               <agentdomain>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Financial</tyvalue>
                   </typename>
               </agentdomain>
               <description>
                   <short>Local Government Grant</short>
               </description>
            </agent>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_agnt_001/iden_agnt_001.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_6006’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of agent and their domain is defined in lines 18 and 26 respectively. The structure identifier is given in line 14;

- The agent is the learner’s sponsor and the agent’s formal external identifier is given in line 24 – the nature of this identifier is determined by the actual agent.

This next stage is to add a new agent’s information for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     <learnerinformation>
        <comment>A basic example of agent in an Identification.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_6006</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <agent>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Tutor</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>agent_02</indexid>
                   </referential>
               </contentype>
               <agentid>UniversityStaffNumber</agentid>
               <agentdomain>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Educational</tyvalue>
                   </typename>
               </agentdomain>
               <description>
                   <short>University Academic Tutor</short>
               </description>
            </agent>
        </identification>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/iden_agnt_002/iden_agnt_002.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous contact information name example (lines 6 and 7). It is an implementation dependent issue whether the <identification> identifiers have to be the same in the two examples as given herein (line 14);

- The type of agent and their domain is defined in lines 20 and 31 respectively;

- The agent is the learner’s sponsor and the agent’s formal external identifier is given in line 24 – once again the nature of this identifier is determined by the actual agent.

## 4.7 Interest Examples

This example creates a record containing the interests for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     <learnerinformation>
        <comment>An example of LIP Interest information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>7001</id>
               </sourcedid>
            </referential>
        </contentype>
        <interest>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Recreational</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>interest_02</indexid>
               </referential>
            </contentype>
            <product>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Portfolio</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>product_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Create</tyvalue>
                   </typename>
                   <datetime>2000</datetime>
               </date>
               <description>
                   <short>A picture of the garden</short>
                   <full>
                      <media mediamode="Image" mimetype="image/gif" contentreftype="uri">
                          myfile/garden.gif
                      </media>
                   </full>
               </description>
            </product>
        </interest>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/intt_002/intt_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_7001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of interest record is defined in line 14. The identifier is given in line 19;

- The actual products of the interest, in this case a photograph of the garden, is given in lines 39-46. The date that the photograph was taken is also recorded (lines 32-38).

This next stage is to add further material to the interest record of the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     <learnerinformation>
        <comment>An example of LIP Interest information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>7001</id>
               </sourcedid>
            </referential>
        </contentype>
        <interest>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Recreational</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>interest_02</indexid>
               </referential>
            </contentype>
            <product>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Portfolio</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>product_02</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Create</tyvalue>
                   </typename>
                   <datetime>1999</datetime>
               </date>
               <description>
                   <short>Another picture of the garden</short>
                   <full>
                      <media mediamode="Image" mimetype="image/gif" contentreftype="uri">
                          myfile/garden1.gif
                      </media>
                   </full>
               </description>
            </product>
        </interest>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/intt_003/intt_003.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous contact information name example (lines 6 and 7). The same identifer for the interest is used (line 19) but a different identifer is used to denote a new product to be added to the interest activity (line 29);

- The new interest material is added (lines 39-46) and consists of another photograph. The associated creation date of the photograph is also recorded (lines 32-38).

## 4.8 Qcl Examples

This example creates a new taxi licence record for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     <learnerinformation>
        <comment> A basic example of a QCL.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_8001</id>
               </sourcedid>
            </referential>
        </contentype>
        <qcl>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Licence</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>qcl_01</indexid>
               </referential>
            </contentype>
            <title>Taxi Driver Licence</title>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Government</tyvalue>
               </typename>
               <description>
                   <short>New York State</short>
               </description>
            </organization>
            <registrationno>24785NY</registrationno>
           <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1996:09:01</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Expiry</tyvalue>
               </typename>
               <datetime>2001:08:31</datetime>
            </date>
        </qcl>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/qcln_002/qcln_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_8001’ (lines 6 and 7). This must be used for all further references to this learner;

- The nature of the QCL is denoted as a licence (line 14);

- The core information concerning the licence includes its title (line 21), awarding organisation (lines 22-30), registration number (line 31) and start (lines 32-38) and expiry (lines 39-44) dates.

This next stage is to create a new certification for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     <learnerinformation>
        <comment> A basic example of a QCL.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_8001</id>
               </sourcedid>
            </referential>
        </contentype>
        <qcl>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Certification</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>qcl_02</indexid>
               </referential>
            </contentype>
            <title>Taxi Maintenance</title>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Training</tyvalue>
               </typename>
               <description>
                   <short>Taxi Training Institute</short>
               </description>
            </organization>
            <registrationno>TTI_23498</registrationno>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Award</tyvalue>
               </typename>
               <datetime>1998:011</datetime>
            </date>
        </qcl>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/qcln_003/qcln_003.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous qcl example (lines 6 and 7).

- The new qcl is identified by the index shown in line 18 i.e. this qcl identifier must not have been used previously;

- The training certification (denoted in line 14) information is described as title (line 21), accrediting organisation (lines 22-30), registration number of the award (line 31) and the date of the award (lines 32-38).

## 4.9 Relationship Examples

This example creates the relationships between a qcl and activities for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     <learnerinformation>
        <comment>A basic example of a Relationship.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_9001</id>
               </sourcedid>
            </referential>
        </contentype>
        <relationship>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Qcl</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>relationship_01</indexid>
               </referential>
            </contentype>
            <tuple>
               <tuplesource>
                   <indexid>qcl_213</indexid>
               </tuplesource>
               <tuplerelation>
                   <typename>
                      <tyvalue>resultsfrom</tyvalue>
                   </typename>
               </tuplerelation>
               <tupledest>
                   <indexid>activity_21</indexid>
               </tupledest>
               <tupledest>
                   <indexid>activity_22</indexid>
               </tupledest>
            </tuple>
            <description>
               <short>The qualification results from the two activities</short>
            </description>
        </relationship>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/rltp_002/rltp_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_9001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of relationship is defined as a qcl (line 14). The unique data structure is assigned in line 19;

- The source of the relationship is defined as a qcl (lines 23-25), the type of relationship (lines 26-30) and the two destination structures (lines 31-33). A brief explanation of the structure is given in lines 34-36.

This next stage is to create a new relationship for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     <learnerinformation>
        <comment>A basic example of a Relationship.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>basic_9001</id>
               </sourcedid>
            </referential>
        </contentype>
        <relationship>
            <contentype>
               <referential>
                   <indexid>relationship_02</indexid>
               </referential>
            </contentype>
            <tuple>
               <tuplesource>
                   <sourcedid>
                      <source>SOURCE1</source>
                      <id>6294UoD</id>
                   </sourcedid>
                   <indexid/>
               </tuplesource>
               <tuplerelation>
                   <typename>
                      <tyvalue>equivalent</tyvalue>
                   </typename>
               </tuplerelation>
               <tupledest>
                   <sourcedid>
                      <source>SOURCE2</source>
                      <id>UserOrg22</id>
                   </sourcedid>
                   <indexid/>
               </tupledest>
            </tuple>
            <description>
               <short>These two sourcedids refer to the same learner</short>
            </description>
        </relationship>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/rltp_002/rltp_003.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous relationship example (lines 6 and 7).

- The new relationship is identified by the index shown in line 14. Its type is given in line 28;

- The core of the relationship shows how different sourcedids can be shown to be equivalent (lines 18-38).

## 4.10 Securitykey Examples

This example creates a new security key record for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     <learnerinformation>
        <comment>An example of LIP Securitykey information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>10001</id>
               </sourcedid>
            </referential>
        </contentype>
        <securitykey>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Password</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>securitykey_1</indexid>
               </referential>
            </contentype>
            <keyfields>
               <fieldlabel>
                   <typename>
                      <tyvalue>Password</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>1fotcn</fielddata>
            </keyfields>
        </securitykey>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1Examples/Valid/Basic/skey_002/skey_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_10001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of security key information (line 14) and the associated identifier (line 19) is defined;

- The actual password is defined (line 29) and the associated field name is identified in lines 24-28.

This next stage is to store a PIN number for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     <learnerinformation>
        <comment>An example of LIP Securitykey information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>10001</id>
               </sourcedid>
            </referential>
        </contentype>
        <securitykey>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>PIN</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>securitykey_2</indexid>
               </referential>
            </contentype>
            <keyfields>
               <fieldlabel>
                   <typename>
                      <tyvalue>PhotoCopyCard</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>5760</fielddata>
            </keyfields>
        </securitykey>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/skey_003/skey_003.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_10001’ (lines 6 and 7). This is the same as for the previous securitykeys example;

- The type of security key information (line 14) and the associated identifier (line 19) is defined. This identifier is different from the previous example;

- The actual code is defined (line 28) and the associated field name is identified in lines 23-27.

## 4.11 Transcript Examples

This example creates a transcript for a learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     <learnerinformation>
        <comment>An example of LIP Transcript information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>11001</id>
               </sourcedid>
            </referential>
        </contentype>
        <transcript>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Vocational</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>transcript_01</indexid>
               </referential>
            </contentype>
            <exrefrecord>
               <recformat>MSWord98</recformat>
               <recdata uri="employee1/reference.doc"/>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Create</tyvalue>
                   </typename>
                   <datetime>1999:10:31</datetime>
               </date>
            </exrefrecord>
            <description>
               <short>Line manager employment transcript on the learner</short>
            </description>
        </transcript>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/trns_002/trns_002.xml. The key features of this example are:

- The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0_Example:basic_11001’ (lines 6 and 7). This must be used for all further references to this learner;

- The type of transcript is defined in line 14. The identifier is given in line 19;

- The actual transcript is defined in terms of its format (line 23) and the external reference to the material itself (line 24). The date of creation is also stored (lines 25-31).

This next stage is to add another transcript for the same learner. The example contains all of the IMS LIP information required to construct the instance record.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     <learnerinformation>
        <comment>An example of LIP Transcript information.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>11001</id>
               </sourcedid>
            </referential>
        </contentype>
        <transcript>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Vocational</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>transcript_02</indexid>
               </referential>
            </contentype>
            <exrefrecord>
               <recformat>PDF</recformat>
               <recdata uri="employee1/reference1.pdf"/>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Create</tyvalue>
                   </typename>
                   <datetime>2000:10:31</datetime>
               </date>
            </exrefrecord>
        </transcript>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/trns_003/trns_003.xml. The key features of this example are:

- The same <sourcedid> must be used as per the previous transcript (lines 6 and 7). A new identifer for the transcript is used (line 19) and the type of transcript is defined (line 14);

- The actual transcript is defined in terms of its format (line 23) and the external reference to the material itself (line 24). The date of creation is also stored (lines 25-31).

[1] The ANSI TS 130 definition of a transcript is more formal than that adopted as one of the core data structures in the IMS LIP. A TS 130 transcript is one of the possible documents that could be referenced by an IMS LIP instance.

[2] The XML schema trees shown in this document were generated by the XML Authority product from Extensibility Inc.

# 5. Advanced Example LIP Instances

## 5.1 Engineering Resume

The following is an example of using the LIP-XML to represent an Engineering-oriented resume.

### 5.1.1 The Example

### 5.1.2 The XML Instance

The equivalent XML instance for this resume is (note that this is only one instance of the large number of possible mappings. The actual form adopted should be determined by other factors e.g. to minimise space, for sequential parsing, etc.):

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     72
     73
     74
     75
     76
     77
     78
     79
     80
     81
     82
     83
     84
     85
     86
     87
     88
     89
     90
     91
     92
     93
     94
     95
     96
     97
     98
     99
     100
     101
     102
     103
     104
     105
     106
     107
     108
     109
     110
     111
     112
     113
     114
     115
     116
     117
     118
     119
     120
     121
     122
     123
     124
     125
     126
     127
     128
     129
     130
     131
     132
     133
     134
     135
     136
     137
     138
     139
     140
     141
     142
     143
     144
     145
     146
     147
     148
     149
     150
     151
     152
     153
     154
     155
     156
     157
     158
     159
     160
     161
     162
     163
     164
     165
     166
     167
     168
     169
     170
     171
     172
     173
     174
     175
     176
     177
     178
     179
     180
     181
     182
     183
     184
     185
     186
     187
     188
     189
     190
     191
     192
     193
     194
     195
     196
     197
     198
     199
     200
     201
     202
     203
     204
     205
     206
     207
     208
     209
     210
     211
     212
     213
     214
     215
     216
     217
     218
     219
     220
     221
     221
     222
     223
     224
     225
     226
     227
     228
     229
     230
     231
     232
     233
     234
     235
     236
     237
     238
     239
     240
     241
     242
     243
     244
     245
     246
     247
     248
     249
     250
     251
     252
     253
     254
     255
     256
     257
     258
     259
     260
     261
     262
     263
     264
     265
     266
     267
     268
     269
     270
     271
     272
     273
     274
     275
     276
     277
     278
     279
     280
     281
     282
     283
     284
     285
     286
     287
     288
     289
     290
     291
     292
     293
     294
     295
     296
     297
     298
     299
     300
     301
     302
     303
     304
     305
     306
     307
     308
     309
     310
     311
     312
     313
     314
     315
     316
     317
     318
     319
     320
     321
     322
     323
     324
     325
     326
     327
     328
     329
     330
     331
     332
     333
     334
     335
     336
     337
     338
     339
     340
     341
     342
     343
     344
     345
     346
     347
     348
     349
     350
     351
     352
     353
     354
     355
     356
     357
     358
     359
     360
     361
     362
     363
     364
     365
     366
     367
     368
     369
     370
     371
     372
     373
     374
     375
     376
     377
     378
     379
     380
     381
     382
     383
     384
     385
     386
     387
     388
     389
     390
     391
     392
     393
     394
     395
     396
     397
     398
     399
     400
     401
     402
     403
     404
     405
     406
     407
     408
     409
     410
     411
     412
     413
     414
     415
     416
     417
     418
     419
     420
     421
     422
     423
     424
     425
     426
     427
     428
     429
     430
     431
     432
     433
     434
     435
     436
     437
     438
     439
     440
     441
     442
     443
     444
     445
     446
     447
     448
     449
     450
     451
     452
     453
     454
     455
     456
     457
     458
     459
     460
     461
     462
     463
     464
     465
     466
     467
     468
     469
     470
     471
     472
     473
     474
     475
     476
     477
     478
     479
     480
     481
     482
     483
     484
     485
     486
     487
     488
     489
     490
     491
     492
     493
     494
     495
     496
     497
     498
     499
     500
     501
     502
     503
     504
     505
     506
     507
     508
     509
     510
     511
     512
     513
     514
     515
     516
     517
     518
     519
     520
     521
     522
     523
     524
     525
     526
     527
     528
     529
     530
     531
     532
     533
     534
     535
     536
     537
     538
     539
     540
     541
     542
     543
     544
     545
     546
     547
     548
     549
     550
     551
     552
     553
     554
     555
     556
     557
     558
     559
     560
     561
     562
     563
     564
     565
     567
     568
     569
     570
     571
     572
     573
     574
     575
     576
     577
     578
     579
     580
     581
     582
     583
     584
     585
     586
     587
     588
     589
     590
     591
     592
     593
     594
     595
     596
     597
     598
     599
     600
     601
     602
     603
     604
     605
     606
     607
     608
     609
     610
     611
     612
     613
     614
     615
     616
     617
     618
     619
     620
     621
     622
     623
     624
     625
     626
     627
     628
     629
     630
     631
     632
     633
     634
     635
     636
     637
     638
     639
     640
     641
     642
     643
     644
     645
     646
     647
     648
     649
     650
     651
     652
     653
     654
     655
     656
     657
     658
     659
     660
     661
     662
     663
     664
     665
     666
     667
     668
     669
     670
     671
     672
     673
     674
     675
     676
     677
     678
     679
     680
     681
     682
     683
     684
     685
     686
     687
     688
     689
     690
     691
     692
     693
     694
     695
     696
     697
     698
     699
     700
     701
     702
     703
     704
     705
     706
     707
     708
     709
     <learnerinformation>
        <comment>An example Engineering Resume.</comment>
        <contentype>
            <referential>
               <sourcedid>
                   <source>IMS_LIP_V1p0_Example</source>
                   <id>colinsmythe</id>
               </sourcedid>
            </referential>
        </contentype>
        <identification>
            <contentype>
               <referential>
                   <indexid>identification_01</indexid>
               </referential>
            </contentype>
            <name>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Preferred</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>name_01</indexid>
                   </referential>
               </contentype>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>First</tyvalue>
                   </typename>
                   <text>Colin</text>
               </partname>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Last</tyvalue>
                   </typename>
                   <text>Smythe</text>
               </partname>
               <partname>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Suffix</tyvalue>
                   </typename>
                   <text>BSc, PhD, FBCS, C.Eng</text>
               </partname>
            </name>
            <address>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>address_01</indexid>
                   </referential>
               </contentype>
               <street>
                   <streetnumber>34</streetnumber>
                   <streetname>Acorn Hill</streetname>
               </street>
               <locality>Stannington</locality>
               <city>Sheffield</city>
               <postcode>S66AW</postcode>
            </address>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contact_01</indexid>
                   </referential>
               </contentype>
                   <telephone>
                      <countrycode>44</countrycode>
                      <areacode>0114</areacode>
                      <indnumber>2334009</indnumber>
                   </telephone>
            </contactinfo>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contact_02</indexid>
                   </referential>
               </contentype>
                   <facsimile>
                      <countrycode>44</countrycode>
                      <areacode>0114</areacode>
                      <indnumber>2334009</indnumber>
                   </facsimile>
            </contactinfo>
            <contactinfo>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>contact_03</indexid>
                   </referential>
               </contentype>
                   <email>colin@dunelm.com</email>
            </contactinfo>
            <demographics>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Adult</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>demographics_01</indexid>
                   </referential>
               </contentype>
               <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Birth</tyvalue>
               </typename>
                   <datetime>1958:02:18</datetime>
               </date>
            </demographics>
            <ext_identification>
               <fieldlabel>
                   <typename>
                      <tyvalue>Nationality</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>British</fielddata>
            </ext_identification>
        </identification>
        <qcl>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Qualification</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>qcl_01</indexid>
               </referential>
            </contentype>
            <title>PhD in Communications</title>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Educational</tyvalue>
               </typename>
               <description>
                   <short>University of Durham</short>
               </description>
            </organization>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1982</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1985</datetime>
            </date>
        </qcl>
        <qcl>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Qualification</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>qcl_02</indexid>
               </referential>
            </contentype>
            <title>BSc in Applied Physics</title>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Educational</tyvalue>
               </typename>
               <description>
                   <short>University of Durham</short>
               </description>
            </organization>
            <level>
               <text>Honours</text>
            </level>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1976</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1979</datetime>
            </date>
        </qcl>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_01</indexid>
               </referential>
            </contentype>
            <classification>Fellow</classification>
            <role>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Member</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>role_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
            </role>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Professional</tyvalue>
               </typename>
               <description>
                   <short>British Computer Society</short>
               </description>
            </organization>
        </affiliation>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_02</indexid>
               </referential>
            </contentype>
            <classification>Member</classification>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Professional</tyvalue>
               </typename>
               <description>
                   <short>IEEE</short>
               </description>
            </organization>
        </affiliation>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_03</indexid>
               </referential>
            </contentype>
            <classification>Member</classification>
            <organization>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Professional</tyvalue>
               </typename>
               <description>
                   <short>ACM</short>
               </description>
            </organization>
        </affiliation>
        <affiliation>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Professional</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>affiliation_04</indexid>
               </referential>
            </contentype>
            <classification>Chartered Engineer</classification>
            <role>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Member</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>role_04</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
            </role>
        </affiliation>
        <transcript>
            <contentype>
               <referential>
                   <indexid>transcript_01</indexid>
               </referential>
            </contentype>
            <description>
               <short>Primary Skills</short>
               <long>
                   Networks consultancy (Data networking and internetworking) - Ten years
                   Standards and specification development - Five years
                   Project management (inc. European projects)    Ten years
                   Proposal tendering and writing (inc. European projects) - Fifteen years
                   Computer systems implementation (inc. C) - Twenty years
                   IT training (Data networking and software engineering) - Ten years
               </long>
            </description>
        </transcript>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_01</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1998:06</datetime>
            </date>
            <description>
               <short>Dunelm Services Limited</short>
               <long>
                   Co-founder and Director of Dunelm Systems Ltd.  Dunelm specialises in
                   providing: consultancy and implementation skills in Information and
                   Communications Technology (ICT); and IT training in Data Networking and
                   Software Engineering.
               </long>
            </description>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_01_subactivity_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1999</datetime>
               </date>
               <description>
                   <short>DISTRIBUTED LEARNING SPECIFICATIONS(24 months)</short>
                   <long>
                      Responsible for the editing and authoring of the IMS Question
                      and Test Interoperability, and the Learner Information Packaging
                      Specifications.
                   </long>
               </description>
            </activity>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_01_subactivity_02</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1995</datetime>
               </date>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Finish</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
               <description>
                   <short>RENAISSANCE Project - ACTS AC100 (30 months)</short>
                   <long>
                      Responsible for the development of CBT materials (inc. HTML)
                      used on a Pan-European demonstrator.
                   </long>
               </description>
            </activity>
        </activity>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_02</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1992:08</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1999:10</datetime>
            </date>
            <description>
               <short>University of Sheffield</short>
               <long>
                   A member of the Department of Computer Science which consists of
                   26 full-time academics, 2 EPSRC Advanced Research Fellows, 7
                   technical staff, 7 secretaries, 35 research assistants, 55
                   PhD/MPhil research students, 350 undergraduates and 60 MRes/MSc
                   postgraduates.
               </long>
            </description>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_02_subactivity_01</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1997</datetime>
               </date>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Finish</tyvalue>
                   </typename>
                  <datetime>1999</datetime>
               </date>
               <description>
                   <short>Full Professor of Computer Science</short>
                   <long>
                      Head of the Communications and Distributed Systems Research
                      Group (CDSRG), a team of 40 staff and research students.
                   </long>
               </description>
            </activity>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_02_subactivity_02</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1994</datetime>
               </date>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Finish</tyvalue>
                   </typename>
                   <datetime>1998</datetime>
               </date>
               <description>
                   <short>Head of Department</short>
                   <long>
                      During that period the Department established itself as one of
                      the most rapidly improving Computer Science departments in the UK.
                   </long>
               </description>
            </activity>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_02_subactivity_03</indexid>
                   </referential>
               </contentype>
               <date>
                   <typename>
                      <tysource sourcetype="imsdefault"/>
                      <tyvalue>Start</tyvalue>
                   </typename>
                   <datetime>1995</datetime>
               </date>
               <description>
                   <short>Author</short>
                   <long>
                      Internetworking - Designing the Right Architectures, Addison-
                      Wesley Longmans, p.471, ISBN 0-201-56536-6.
                   </long>
               </description>
            </activity>
        </activity>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_03</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1985:07</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1989:05</datetime>
            </date>
            <description>
               <short>Hyperion Systems Limited</short>
               <long>
                   Co-founder and Director of Hyperion Systems Ltd, a systems house
                   specialising in the provision of Computing and Communication services.
                   Roles adopted during this period were those of Managing Director,
     Marketing Director, Company Secretary and Principal Consultant.
               </long>
            </description>
        </activity>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_04</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1986:01</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1992:07</datetime>
            </date>
            <description>
               <short>University of Surrey</short>
               <long>
                   Lecturer in Data Communications within the Department of
                   Electronic and Electrical Engineering.
               </long>
            </description>
        </activity>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_05</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1982:02</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1985:12</datetime>
            </date>
            <description>
               <short>University of Durham</short>
               <long>
                   Lecturer in Digital Electronics within the department of Applied
                   Physics and Electronics. Studied PhD entitled Direct Sequence
                   Spread Spectrum Techniques in Local Area Networks.
               </long>
            </description>
        </activity>
        <activity>
            <typename>
               <tysource sourcetype="imsdefault"/>
               <tyvalue>Work</tyvalue>
            </typename>
            <contentype>
               <referential>
                   <indexid>activity_06</indexid>
               </referential>
            </contentype>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Start</tyvalue>
               </typename>
               <datetime>1979:10</datetime>
            </date>
            <date>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Finish</tyvalue>
               </typename>
               <datetime>1982:02</datetime>
            </date>
            <description>
               <short>Logica Limited</short>
            </description>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_6_subactivity_01</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>Senior designer for the communications software of an OSI/RM
                      based architecture.  Responsible for a three man team.
                   </short>
               </description>
            </activity>
            <activity>
               <typename>
                   <tysource sourcetype="imsdefault"/>
                   <tyvalue>Work</tyvalue>
               </typename>
               <contentype>
                   <referential>
                      <indexid>activity_6_subactivity_02</indexid>
                   </referential>
               </contentype>
               <description>
                   <short>
                      Member of a 30 person team producing a cabin simulation of the
                      EH101 helicopter for Westland Helicopters.
                   </short>
               </description>
            </activity>
        </activity>
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Advanced/engresume_001/engresume_001.xml

### 5.1.3 Key Features of the Engineering Resume Example

The key features of this example are:

- The sourcedid for the the learner is defined in the <contentype> element in lines 3-10;

- The name on the CV (line 1) is held within the XML instance as a name (lines 17-48). Note that the ‘BSc, PhD…” part is held as a partname suffix (lines 41-47);

- The contact address on the CV (line 4) is contained within the address element within the XML instance (lines 49-66);

- The telephone, fax and email information from the CV (lines 5-6) are contained within the <contactinfo> elements within the XML instance (lines 67-110). All of the contact information is typed a ‘Work’ related (lines 70, 86 and 102). The telephone number is given in lines 77-81, the fax number in lines 93-97 and the email address as lines 109;

- The date of birth information from the CV (line 7) is contained within the <demographics> information in the XML instance (line 111-128);

- The nationality infromation from the CV (line 8) is given as an extension to the identification element in the XML instance (lines 129-136);

- The education information from the CV (line9) is contained within the XML instance as <qcl> (lines 138-210). The PhD information is stored in lines 138-172 with the associated dates (158-171), title (line 148) and awarding institution (lines 113-118). The degree information is stored in lines 171-210 with the associated dates (lines 196-209), title (line 183) and awarding institution (lines 184-192);

- The affiliations information in the CV (lines 10-11) are contained within the <affiliation> elements in the XML instance (lines 211-320). The British Computer Society affiliation is stored in lines 211-248 with the associated classification (line 221) and date (lines 231-237). The ‘IEEE’ and ‘ACM’ affiliations are stored in lines 249-269 and 270-290 respectively. In each case only the classification is required as there are no roles or associated dates to be stored. The ‘Chartered Engineer’ information is stored in lines 291-320 with classification (line 301) and date (lines 321-318);

- The ‘Experience …’ information in the CV (line 12) is not included in the XML instance;

- The ‘Primary Skills’ information in the CV (lines 13-19) are contained with the <transcript> element within the XML instance (lines 321-338). This information is included within the <description> element (lines 240-247);

- The ‘Detailed Job History’ information from the CV (lines 20-58) is contained within the XML instance as a set of hierarchically related activities (lines 339-708). Ecah of the top level activities are defined within their own group of hierarchical <activity> elements;

- The ‘Dunelm Services Limited’ work experience (CV lines 22-30) is defined in lines 339-423. The core information is defined in the associated <activity> description (lines 356-364) and date (lines 349-355). The two ‘Responsibilities and achievements’ (CV lines 26-30) are included as sub-activities within the XML instance (lines 365-390 and 391-422 respectively). In each case the corresponding dates and descriptions are included;

- The ‘University of Sheffield’ work experience (CV lines 33-42) is defined in lines 424-547. The core information is defined in the associated <activity> description (lines 448-457) and dates (lines 434-447). The three ‘Responsibilities and achievements’ (CV lines 38-42) are included as sub-activities within the XML instance (lines 458-489, 490-521 and 522-546 respectively). In each case the corresponding dates and descriptions are included;

- The ‘Hyperion Systems Limited’ work experience (CV lines 43-46) is defined in lines 548-582. The core information is defined in the associated <activity> description (lines 573-581) and dates (lines 558-572);

- The ‘University of Surrey’ work experience (CV lines 48-49) is defined in lines 583-614. The core information is defined in the associated <activity> description (lines 607-613) and date (lines 593-606);

- The ‘University of Durham’ work experience (CV lines 50-53) is defined in lines 615-647. The core information is defined in the associated <activity> description (lines 625-638) and dates (lines 639-646);

- The ‘Logica Limited’ work experience (CV lines 54-58) is defined in lines 648-708. The core information is defined in the associated <activity> description (lines 672-674) and dates (lines 658-671). The two ‘Responsibilities and achievements’ (CV lines 56-58) are included as sub-activities within the XML instance (lines 675-690 and 691-707 respectively). In each case the corresponding dates and descriptions are included.

## 5.2 FEFC Funding Records Exchange

The following is an example of using the IMS LIP to support the exchange of funding record information.

### 5.2.1 The Example

The Further Education Funding Council (FEFC) within the UK is evaluating the IMS LIP to support the exchange of Individualised Student Records (ISRs). An ISR describes a student attending a particular college and is used by the FEFC to determine the amount of funding the college should receive as a result of the attendance of that student. The structure of an ISR is given in Table 5.1.

Table 5.1 ISR mapping to the IMS LIP.

Field Number | Field Name | IMS LIP Data Structures
S01 | Student Data Set Reference | <identification><contentype>
S02 | Student surname/family name | <identification><name>
S03 | Student initials | <identification><name>
S04 | Date of birth | <identification><demographics><date>
S05 | Sex | <identification><demographics><gender>
S06 | Home postcode | <identification><address><postcode>
S07 | Country of domicile | <identification><address><country>
S08 | Ethnicity | <identification><ext_identification>
S09 | Learning difficulties and/or disabilities | <accessibility><disability><ext_disability>
S10A | Additional support cost | <accessibility><eligibility><ext_eligibility>
S11 | Additional support assessment | <accessibility><eligibility><ext_eligibility>
S12 | Destination | <activity><status>
S14A | Annual fees indicator | <accessibility><eligibility><ext_eligibility>
S14B | Amount of tuition fees received or expected for the student | <accessibility><eligibility><ext_eligibility>
S15 | Reason for partial or full non-payment of tuition fees | <accessibility><eligibility><ext_eligibility>
S16 | Major source of tuition fees | <identification><agent>
S17 | Institution-specified data 1 | <learnerinformation><ext_learnerinfo>
S18 | Institution-specified data 2 | <learnerinformation><ext_learnerinfo>
S19 | GCE/GCSE boards’ reference | <identification><demographics><uid>
S20 | Widening participation factor | <accessibility><eligibility><ext_eligibility>
S21 | Widening participation category | <identification><ext_identification>
S22 | Status of qualification on entry data | <transcript>
S23 | Student initiative | <accessibility><eligibility><ext_eligibility>
S24 | Residential Accommodation | <identification><ext_identification>
S25 | Childcare | <accessibility><eligibility><ext_eligibility>
S26 | Disability | <accessibility><disability><ext_disability>
S27 | Learning difficulty | <accessibility><disability><ext_disability>
S28 | 16-18 year old full-time funding entitlement | <accessibility><eligibility><ext_eligibility>
S29 | National Insurance number | <identification><demographics><uid>
SHE01 | Highest qualification on entry | <transcript>
SHE02 | A/AS level score | <transcript>
SHE03 | Nationality | <identification><ext_identification>
SHE04 | UCAS Applicant number | <identification><demographics><uid>
SHE05 | New entrant to HE | <activity><status>
SHE06 | Term-time accommodation | <identification><address>
SHE07 | Reason for Leaving | <activity><status>
SHE09 | Type of programme year | <activity><status>
SHE10 | Mode applicable to funding Council Early Statistics/HEIFES | <activity><definition>
SHE11 | Level applicable to funding Council HEIFES | <activity><definition>
SHE12 | Completion of year of programme of study | <activity><status>
SHE13 | Student FTE | <identification><ext_identification>
Q01 | Qualification aim data set reference | <identification><contentype>
Q02 | Qualification reference code | <activity><learningactivityref>
Q05 | Type of tuition fees | <accessibility><eligibility><ext_eligibility>
Q07A | Annual fees indicator | <accessibility><eligibility><ext_eligibility>
Q07B | Amount of tuition fees received or expected for the student | <accessibility><eligibility><ext_eligibility>
Q08 | Reason for partial or full non-payment of tuition fees | <accessibility><eligibility><ext_eligibility>
Q09 | Major source of tuition fees | <identification><agent>
Q10 | Council or HEFCE funding | <identification><agent>
Q11 | Major source of funding other than tuition fees and Council/HEFCE funding | <identification><agent>
Q12 | Minor source of funding other than tuition fees and Council/HEFCE funding | <identification><agent>
Q13 | Franchised-out arrangements | <identification><agent>
Q15 | Expected guided learning hours | <activity><units>
Q16 | Start date | <activity><date>
Q17 | Expected end date | <activity><date>
Q18 | Actual end date | <activity><date>
Q19 | Completion status | <activity><status>
Q20 | Outcome | <activity><evaluation>
Q21 | Grade | <activity><evaluation>
Q22 | Resit | <activity><status>
Q24 | Institution-specified data 1 | <learnerinformation><ext_learnerinfo>
Q25 | Institution specified data 2 | <learnerinformation><ext_learnerinfo>
Q26 | NVQ delivery arrangement | <accessibility><eligibility><ext_eligibility>
Q28 | Expected end date at 1 February | <activity><date>
Q29 | Government initiative | <activity><status>
Q30 | Franchising partner | <activity><learningactivityref>
Q31 | Implied rate of Council partial funding for ESF in Q11 | <accessibility><eligibility><ext_eligibility>
Q32 | Implied rate of Council partial funding for ESF in Q12 | <accessibility><eligibility><ext_eligibility>
Q33 | APL hours | <activity><units>
Q34 | Delivery mode | <activity><definition>
Q35 | Employer role | <identification><agent>
Q36 | Main delivery method | <activity><definition>
Q37 | Actual guided learning hours | <activity><units>
QHE01 | Major source of tuition fees | <accessibility><eligibility><ext_eligibility>
QHE02 | Year of programme | <activity><date>
E01 | Qualification on entry data set reference | <identification><contentype>
E02 | Qualification on entry reference code | <qcl>
E03 | Grade | <qcl>
E04 | Date awarded | <qcl>

There are several ways in which the ISR can be mapped to the IMS LIP. Two examples are described (version 1 and version 2 in sub-sections 5.2.2 and 5.2.3 respectively) and the rational for the approach taken is briefly indicated at the start of each case.

### 5.2.2 The Instance – Version 1

In this example of the ISR mapping, the approach has been to minimise the size of the XML instance.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     72
     73
     74
     75
     76
     77
     78
     79
     80
     81
     82
     83
     84
     85
     86
     87
     88
     89
     90
     91
     92
     93
     94
     95
     96
     97
     98
     99
     100
     101
     102
     103

    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
    275
    276
    277
    278
    279
    280
    281
    282
    283
    284
    285
    286
    287
    288
    289
    290
    291
    292
    293
    294
    295
    296
    297
    298
    299
    300
    301
    302
    303
    304
    305
    306
    307
    308
    309
    310
    311
    312
    313
    314
    315
    316
    317
    318
    319
    320
    321
    322
    323
    324
    325
    326
    327
    328
    329
    330
    331
    332
    333
    334
    335
    336
    337
    338
    339
    340
    341
    342
    343
    344
    345
    346
    347
    348
    349
    350
    351
    352
    353
    354
    355
    356
    357
    358
    359
    360
    361
    362
    363
    364
    365
    366
    367
    368
    369
    370
    371
    372
    373
    374
    375
    376
    377
    378
    379
    380
    381
    382
    383
    384
    385
    386
    387
    388
    389
    390
    391
    392
    393
    394
    395
    396
    397
    398
    399
    400
    401
    402
    403
    404
    405
    406
    407
    408
    409
    410
    411
    412
    413
    414
    415
    416
    417
    418
    419
    420
    421
    422
    423
    424
    425
    426
    427
    428
    429
    430
    431
    432
    433
    434
    435
    436
    437
    438
    439
    440
    441
    442
    443
    444
    445
    446
    447
    448
    449
    450
    451
    452
    453
    454
    455
    456
    457
    458
    459
    460
    461
    462
    463
    464
    465
    466
    467
    368
    469
    470
    471
    472
    473
    474
    475
    476
    477
    478
    479
    480
    481
    482
    483
    484
    485
    486
    487
    488
    489
    490
    491
    492
    493
    493
    495
    496
    497
    498
    499
    500
    501
    502
    503
    504
    505
    506
    507
    508
    509
    510
    511
    512
    513
    514
    515
    516
    517
    518
    519
    520
    521
    522
    523
    524
    525
    526
    527
    528
    529
    530
    531
    532
    533
    534
    535
    536
    537
    538
    539
    540
    541
    542
    543
    544
    545
    546
    547
    548
    549
    550
    551
    552
    553
    554
    556
    557
    558
    559
    560
    561
    562
    563
    564
    565
    566
    567
    568
    569
    570
    571
    572
    573
    574
    575
    576
    577
    578
    579
    580
    581
    582
    583
    584
    585
    586
    587
    588
    589
    590
    591
    592
    593
    594
    595
    596
    597
    598
    599
    600
    601
    602
    603
    604
    605
    606
    607
    608
    609
    610
    611
    612
    613
    614
    615
    616
    617
    618
    619
    620
    621
    622
    623
    624
    625
    626
    627
    628
    629
    630
    631
    632
    633
    634
    635
    636
    637
    638
    639
    640
    641
    642
    643
    644
    645
    646
    647
    648
    649
    650
    651
    652
    653
    654
    655
    656
    657
    658
    659
    660
    661
    662
    663
    664
    665
    666
    667
    668
     <!-- This is an example, of what an instance of the ISR       -->
     <!-- would look like when using the IMS LIP framework  -->
     <!-- with the required extensions.  This approach is          -->
     <!-- optimised to minimise the XML instance size.             -->
     <learnerinformation>
        <!--**************************************************S01_Structure-->
        <contentype>
            <referential>
               <indexid>Entry</indexid>
            </referential>
        </contentype>
        <!--***************************************************************-->
        <!--********************************Student Data Set Identification-->
        <identification>
            <name>
               <!--******************************************S02_Structure-->
               <partname>
                   <text>Entry</text>
               </partname>
               <!--*******************************************************-->
               <!--******************************************S03_Structure-->
               <partname>
                   <text>Entry</text>
               </partname>
               <!--*******************************************************-->
            </name>
            <demographics>
               <!--******************************************S05_Structure-->
               <gender gender="NA"/>
               <!--*******************************************************-->
               <!--******************************************S04_Structure-->
               <date>
                   <datetime>Entry</datetime>
               </date>
               <!--*******************************************************-->
               <!--******************************************S19_Structure-->
               <uid>Entry</uid>
               <!--*******************************************************-->
            </demographics>
            <address>
               <!--****************************************SHE06_Structure-->
               <street>
                   <nonfieldedstreetaddress>Entry</nonfieldedstreetaddress>
               </street>
               <!--*******************************************************-->
               <!--******************************************S07_Structure-->
               <country>Entry</country>
               <!--*******************************************************-->
               <!--******************************************S06_Structure-->
               <postcode>Entry</postcode>
               <!--*******************************************************-->
            </address>
            <!--**********************************************S16_Structure-->
            <agent>
               <agentid>MajorSourceTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************S29_Structure-->
            <demographics>
               <uid>Entry</uid>
            </demographics>
            <!--***********************************************************-->
            <!--********************************************SHE04_Structure-->
            <demographics>
               <uid>Entry</uid>
            </demographics>
            <!--***********************************************************-->
            <ext_identification>
               <!--******************************************S08_Structure-->
               <fieldlabel>
                   <typename>
                      <tyvalue>Ethnicity</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
               <!--*******************************************************-->
               <!--******************************************S21_Structure-->
               <fieldlabel>
                   <typename>
                      <tyvalue>WideningParticpationCategory</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
               <!--*******************************************************-->
               <!--******************************************S24_Structure-->
               <fieldlabel>
                   <typename>
                      <tyvalue>ResidentialAccomodation</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
               <!--*******************************************************-->
               <!--****************************************SHE03_Structure-->
               <fieldlabel>
                   <typename>
                      <tyvalue>ISR_Nationality</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
               <!--*******************************************************-->
               <!--****************************************SHE13_Structure-->
               <fieldlabel>
                   <typename>
                      <tyvalue>StudentFTE</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
               <!--*******************************************************-->
            </ext_identification>
        </identification>
        <!--********************************Student Data Set Identification-->
        <!--*********************************Student Data Set Accessibility-->
        <accessibility>
            <disability>
               <ext_disability>
                   <!--**************************************S09_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>LearningDifficulties</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S26_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>Disability</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S27_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>LearningDifficulties</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
               </ext_disability>
            </disability>
            <eligibility>
               <ext_eligibility>
                   <!--*************************************S10A_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>AdditionalSupportCost</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S11_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>AdditionalSupportElement</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--*************************************S14A_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>AnnualfeesIndicator</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--*************************************S14B_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>AmountofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S15_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>NonPaymentofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S20_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>WideningParticpationFactor</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S23_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>StudentInitiative</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S25_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>Childcare</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************S28_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>16-18FundingEntitlement</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--*********************************Student Data Set Accessibility-->
        <!--**************************************Student Data Set Activity-->
        <activity>
            <!--**********************************************S12_Structure-->
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
            <!--***********************************************************-->
            <!--********************************************SHE10_Structure-->
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
            <!--***********************************************************-->
            <!--********************************************SHE11_Structure-->
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
            <!--***********************************************************-->
            <!--********************************************SHE05_Structure-->
            <activity>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </activity>
            <!--***********************************************************-->
            <!--********************************************SHE07_Structure-->
            <activity>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </activity>
            <!--***********************************************************-->
            <!--********************************************SHE09_Structure-->
            <activity>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </activity>
            <!--***********************************************************-->
            <!--********************************************SHE12_Structure-->
            <activity>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </activity>
            <!--***********************************************************-->
        </activity>
        <!--**************************************Student Data Set Activity-->
        <!--**************************************************S22_Structure-->
        <transcript>
            <exrefrecord>
               <recformat/>
               <recdata>Entry</recdata>
            </exrefrecord>
        </transcript>
        <!--***************************************************************-->
        <!--************************************************SHE01_Structure-->
        <transcript>
            <exrefrecord>
               <recformat/>
               <recdata>Entry</recdata>
            </exrefrecord>
        </transcript>
        <!--***************************************************************-->
        <!--************************************************SHE02_Structure-->
        <transcript>
            <exrefrecord>
               <recformat/>
               <recdata>Entry</recdata>
            </exrefrecord>
        </transcript>
        <!--***************************************************************-->
        <!--*******************************Student Data Set ext_learnerinfo-->
        <ext_learnerinfo>
            <!--**********************************************S17_Structure-->
            <fieldlabel>
               <typename>
                   <tyvalue>S17_Structure</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
            <!--***********************************************************-->
            <!--**********************************************S18_Structure-->
            <fieldlabel>
               <typename>
                   <tyvalue>S18_Structure</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
            <!--***********************************************************-->
        </ext_learnerinfo>
        <!--*******************************Student Data Set ext_learnerinfo-->
        <!--**********************Qualification Aim Data Set Identification-->
        <identification>
            <!--**********************************************Q01_Structure-->
            <contentype>
               <referential>
                   <indexid>Entry</indexid>
               </referential>
            </contentype>
            <!--***********************************************************-->
            <!--**********************************************Q09_Structure-->
            <agent>
               <agentid>MajorSourceTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************Q10_Structure-->
            <agent>
               <agentid>CouncilorHEFCEFunding</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************Q11_Structure-->
            <agent>
               <agentid>MajorSourceOtherthanTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************Q12_Structure-->
            <agent>
               <agentid>MinorSourceOtherthanTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************Q13_Structure-->
            <agent>
               <agentid>FranchisedOutArrangements</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
            <!--**********************************************Q35_Structure-->
            <agent>
               <agentid>EmployerRole</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
            <!--***********************************************************-->
        </identification>
        <!--**********************Qualification Aim Data Set Identification-->
        <!--***********************Qualification Aim Data Set Accessibility-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <!--**************************************Q05_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>TypeofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--*************************************Q07A_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_AnnualFeesIndicator</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--*************************************Q07B_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_TuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************Q08_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>NonpaymentofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************Q26_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>NVQDeliveryArrangement</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--**************************************Q31_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>ImpliedRateforESFinQ11</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                  <!--***************************************************-->
                   <!--**************************************Q32_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>ImpliedRateforESFinQ12</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
                   <!--************************************QHE01_Structure-->
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_TuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
                   <!--***************************************************-->
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***********************Qualification Aim Data Set Accessibility-->
        <!--****************************Qualification Aim Data Set Activity-->
        <activity>
            <!--**********************************************Q16_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
            <!--**********************************************Q17_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
            <!--**********************************************Q18_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
            <!--**********************************************Q28_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
            <!--********************************************QHE02_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
            <!--**********************************************Q19_Structure-->
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
            <!--***********************************************************-->
            <!--**********************************************Q15_Structure-->
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ExpectedGuidedLearningHours</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </unitsfield>
            </units>
            <!--***********************************************************-->
            <!--**********************************************Q02_Structure-->
            <learningactivityref>
               <text>Entry</text>
            </learningactivityref>
            <!--***********************************************************-->
            <!--**********************************************Q20_Structure-->
            <evaluation>
               <result>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Outcome</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </score>
               </result>
            </evaluation>
            <!--***********************************************************-->
            <!--**********************************************Q21_Structure-->
            <evaluation>
               <result>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Grade</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </score>
               </result>
            </evaluation>
            <!--***********************************************************-->
            <!--**********************************************Q22_Structure-->
            <evaluation>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </evaluation>
            <!--***********************************************************-->
            <!--**********************************************Q29_Structure-->
            <evaluation>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </evaluation>
            <!--***********************************************************-->
            <!--**********************************************Q30_Structure-->
            <learningactivityref>
               <text>Entry</text>
            </learningactivityref>
            <!--***********************************************************-->
            <!--**********************************************Q34_Structure-->
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
            <!--***********************************************************-->
            <!--**********************************************Q36_Structure-->
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
            <!--***********************************************************-->
            <!--**********************************************Q33_Structure-->
            <activity>
               <units>
                   <unitsfield>
                      <fieldlabel>
                          <typename>
                             <tyvalue>APLHours</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </unitsfield>
               </units>
            </activity>
            <!--***********************************************************-->
            <!--**********************************************Q37_Structure-->
            <activity>
               <units>
                   <unitsfield>
                      <fieldlabel>
                          <typename>
                             <tyvalue>ActualGuidedLearningHours</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </unitsfield>
               </units>
            </activity>
            <!--***********************************************************-->
        </activity>
        <!--****************************Qualification Aim Data Set Activity-->
        <!--*************************Qualification Aim Data ext_learnerinfo-->
        <ext_learnerinfo>
            <!--**********************************************Q24_Structure-->
            <fieldlabel>
               <typename>
                   <tyvalue>Q24_Structure</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
            <!--***********************************************************-->
            <!--**********************************************Q25_Structure-->
            <fieldlabel>
               <typename>
                   <tyvalue>Q25_Structure</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
            <!--***********************************************************-->
        </ext_learnerinfo>
        <!--*************************Qualification Aim Data ext_learnerinfo-->
        <!--****************************Qualification on Entry Data Set QCL-->
        <qcl>
            <!--**********************************************E01_Structure-->
            <contentype>
               <referential>
                   <indexid>Entry</indexid>
               </referential>
            </contentype>
            <!--***********************************************************-->
            <!--**********************************************E02_Structure-->
            <registrationno>Entry</registrationno>
            <!--***********************************************************-->
            <!--**********************************************E03_Structure-->
            <level>
               <text>Entry</text>
            </level>
            <!--***********************************************************-->
            <!--**********************************************E04_Structure-->
            <date>
               <datetime>Entry</datetime>
            </date>
            <!--***********************************************************-->
        </qcl>
        <!--****************************Qualification on Entry Data Set QCL-->
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Advanced/isrmapv1_001/isrmapv1_001.xml

### 5.2.3 The Instance – Version 2

In this example of the ISR mapping, the approach has been to ensure that the sequence of the ISR fields is maintained as per the ISR specification. This takes advantage of the LIP’s ability to have multiple instances of each type which can be used in any order. Thus each of the ISRs fields is mapped onto the Information Model’s top level types. The trade-off of maintaining the sequence of the ISR fields is that the resulting XML instance is longer.

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     72
     73
     74
     75
     76
     77
     78
     79
     80
     81
     82
     83
     84
     85
     86
     87
     88
     89
     90
     91
     92
     93
     94
     95
     96
     97
     98
     99
     100
     101
     102
     103

    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
    275
    276
    277
    278
    279
    280
    281
    282
    283
    284
    285
    286
    287
    288
    289
    290
    291
    292
    293
    294
    295
    296
    297
    298
    299
    300
    301
    302
    303
    304
    305
    306
    307
    308
    309
    310
    311
    312
    313
    314
    315
    316
    317
    318
    319
    320
    321
    322
    323
    324
    325
    326
    327
    328
    329
    330
    331
    332
    333
    334
    335
    336
    337
    338
    339
    340
    341
    342
    343
    344
    345
    346
    347
    348
    349
    350
    351
    352
    353
    354
    355
    356
    357
    358
    359
    360
    361
    362
    363
    364
    365
    366
    367
    368
    369
    370
    371
    372
    373
    374
    375
    376
    377
    378
    379
    380
    381
    382
    383
    384
    385
    386
    387
    388
    389
    390
    391
    392
    393
    394
    395
    396
    397
    398
    399
    400
    401
    402
    403
    404
    405
    406
    407
    408
    409
    410
    411
    412
    413
    414
    415
    416
    417
    418
    419
    420
    412
    422
    423
    424
    425
    426
    427
    428
    429
    430
    431
    432
    433
    434
    435
    436
    437
    438
    439
    440
    441
    442
    443
    444
    445
    446
    447
    448
    449
    450
    451
    452
    453
    454
    455
    456
    457
    458
    459
    460
    461
    462
    463
    464
    465
    466
    467
    468
    469
    470
    471
    472
    473
    474
    475
    476
    477
    478
    479
    480
    481
    482
    483
    483
    485
    486
    487
    488
    489
    490
    491
    492
    493
    494
    495
    496
    497
    498
    499
    500
    501
    502
    503
    504
    505
    506
    507
    508
    509
    510
    511
    512
    513
    514
    515
    516
    517
    518
    519
    520
    521
    522
    523
    524
    525
    526
    527
    528
    529
    530
    531
    532
    533
    534
    535
    536
    537
    538
    539
    540
    541
    542
    543
    544
    545
    546
    547
    548
    549
    550
    551
    552
    553
    554
    556
    557
    558
    559
    560
    561
    562
    563
    564
    565
    566
    567
    568
    569
    570
    571
    572
    573
    574
    575
    576
    577
    578
    579
    580
    581
    582
    583
    584
    585
    586
    587
    588
    589
    590
    591
    592
    593
    594
    595
    596
    597
    598
    599
    600
    601
    602
    603
    604
    605
    606
    607
    608
    609
    610
    611
    612
    613
    614
    615
    616
    617
    618
    619
    620
    621
    622
    623
    624
    625
    626
    627
    628
    629
    630
    631
    632
    633
    634
    635
    636
    637
    638
    639
    640
    641
    642
    643
    644
    645
    646
    647
    648
    649
    650
    651
    652
    653
    654
    655
    656
    657
    658
    659
    660
    661
    662
    663
    664
    665
    666
    667
    668
    669
    670
    671
    672
    673
    674
    675
    676
    678
    679
    680
    681
    682
    683
    684
    685
    686
    687
    688
    689
    690
    691
    692
    693
    694
    695
    696
    697
    698
    699
    700
    701
    702
    703
    704
    705
    706
    707
    708
    709
    710
    711
    712
    713
    714
    715
    716
    717
    718
    719
    720
    721
    722
    723
    724
    725
    726
    727
    728
    729
    730
    731
    732
    733
    734
    375
    736
    737
    738
    739
    740
    741
    742
    743
    744
    745
    746
    747
    748
    749
    750
    751
    752
    753
    754
    755
    756
    757
    758
    759
    760
    761
    762
    763
    764
    765
    766
    767
    768
    769
    770
    771
    772
    773
    774
    775
    776
    777
    778
    779
    780
    781
    782
    783
    784
    785
    786
    787
    788
    789
    790
    791
    792
    793
    794
    795
    796
    797
    798
    799
    800
    801
    802
    803
    804
    805
    806
    807
    808
    809
    810
    811
    812
    813
    814
    815
    816
    817
    818
    819
    820
    821
    822
    823
    824
    825
    826
    827
    828
    829
    830
    831
    832
    833
    834
    835
    836
    837
    838
    839
    840
    841
    842
    843
    844
    845
    846
    847
    848
    849
    850
    851
    852
    853
    854
    855
    856
    857
    858
    859
    860
    861
    862
    863
     <!-- This is an example, of what an instance of the ISR       -->
     <!-- would look like when using the IMS LIP framework  -->
     <!-- with the required extensions.  This approach is          -->
     <!-- optimised for sequential parsing of the database.-->
     <learnerinformation>
        <!--**************************************************S01_Structure-->
        <contentype>
            <referential>
               <indexid>Entry</indexid>
            </referential>
        </contentype>
        <!--***************************************************************-->
        <!--**************************************************S02_Structure-->
        <identification>
            <name>
               <partname>
                   <text>Entry</text>
               </partname>
            </name>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S03_Structure-->
        <identification>
            <name>
               <partname>
                   <text>Entry</text>
               </partname>
            </name>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S04_Structure-->
        <identification>
            <demographics>
               <date>
                   <datetime>Entry</datetime>
               </date>
            </demographics>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S05_Structure-->
        <identification>
            <demographics>
               <gender gender="NA"/>
            </demographics>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S06_Structure-->
        <identification>
            <address>
               <postcode>Entry</postcode>
            </address>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S07_Structure-->
        <identification>
            <address>
               <country>Entry</country>
            </address>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S08_Structure-->
        <identification>
            <ext_identification>
               <fieldlabel>
                   <typename>
                      <tyvalue>Ethnicity</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
            </ext_identification>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S09_Structure-->
        <accessibility>
            <disability>
               <ext_disability>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_learndifficulty</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_disability>
            </disability>
        </accessibility>
        <!--***************************************************************-->
        <!--*************************************************S10A_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>AdditionalSupportCost</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************S11_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>AdditionalSupportAssessment</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************S12_Structure-->
        <activity>
            <status>
               <description>
                   <short>Destination</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--*************************************************S14A_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_Annualfeesindicator</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--*************************************************S14B_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_Tuitionfees</tyvalue>
                      </typename>
                  </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************S15_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>NonPaymentofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************S16_Structure-->
        <identification>
            <agent>
               <agentid>MajorSourceTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S17_Structure-->
        <ext_learnerinfo>
            <fieldlabel>
               <typename>
                   <tyvalue>ISR_Instspecificdataset</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
        </ext_learnerinfo>
        <!--***************************************************************-->
        <!--**************************************************S18_Structure-->
        <ext_learnerinfo>
            <fieldlabel>
               <typename>
                   <tyvalue>ISR_Instspecificdataset</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
        </ext_learnerinfo>
        <!--***************************************************************-->
        <!--**************************************************S19_Structure-->
        <identification>
            <demographics>
               <uid>Entry</uid>
            </demographics>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************S20_Structure-->
        <accessibility>
           <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>WideningParticipationFactor</tyvalue>
                      </typename>
                   </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_eligibility>
           </eligibility>
       </accessibility>
       <!--***************************************************************-->
       <!--**************************************************S21_Structure-->
       <identification>               <ext_identification>
              <fieldlabel>
                  <typename>
                     <tyvalue>WideningParticipationCategory</tyvalue>
                  </typename>
              </fieldlabel>
              <fielddata>Entry</fielddata>
           </ext_identification>
       </identification>
       <!--***************************************************************-->
       <!--**************************************************S22_Structure-->
       <transcript>
           <exrefrecord>
              <recformat/>
              <recdata>Entry</recdata>
           </exrefrecord>
       </transcript>
       <!--***************************************************************-->
       <!--**************************************************S23_Structure-->
       <accessibility>             <eligibility>
              <ext_eligibility>
                  <fieldlabel>
                     <typename>
                         <tyvalue>StudentInitiative</tyvalue>
                     </typename>
                  </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_eligibility>
           </eligibility>
       </accessibility>
       <!--***************************************************************-->
       <!--**************************************************S24_Structure-->
       <identification>               <ext_identification>
              <fieldlabel>
                  <typename>
                     <tyvalue>ResidentialAccomodation</tyvalue>
                  </typename>
              </fieldlabel>
              <fielddata>Entry</fielddata>
           </ext_identification>
       </identification>
       <!--***************************************************************-->
       <!--**************************************************S25_Structure-->
       <accessibility>             <eligibility>
              <ext_eligibility>
                  <fieldlabel>
                     <typename>
                         <tyvalue>Childcare</tyvalue>
                     </typename>
                  </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_eligibility>
           </eligibility>
       </accessibility>
       <!--***************************************************************-->
       <!--**************************************************S26_Structure-->
       <accessibility>
           <disability>
              <ext_disability>
                  <fieldlabel>
                     <typename>
                         <tyvalue>ISR_Disability</tyvalue>
                     </typename>
                  </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_disability>
           </disability>
       </accessibility>
       <!--***************************************************************-->
       <!--**************************************************S27_Structure-->               <accessibility>
           <disability>
              <ext_disability>
                  <fieldlabel>
                     <typename>
                         <tyvalue>ISR_Learnerdifficulty</tyvalue>
                     </typename>
                  </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_disability>
           </disability>
       </accessibility>
       <!--***************************************************************-->
       <!--**************************************************S28_Structure-->
       <accessibility>             <eligibility>
              <ext_eligibility>
                  <fieldlabel>
                     <typename>
                         <tyvalue>16-18YearOldFullTimeFundingEntitlement</tyvalue>
                     </typename>
                  </fieldlabel>
                  <fielddata>Entry</fielddata>
              </ext_eligibility>
           </eligibility>
       </accessibility>
       <!--***************************************************************-->
        <!--**************************************************S29_Structure-->
        <identification>
            <demographics>
               <uid>Entry</uid>
            </demographics>
        </identification>
        <!--***************************************************************-->
        <!--*************************************************SHE01_Structure-->
        <transcript>
            <exrefrecord>
               <recformat/>
               <recdata>Entry</recdata>
            </exrefrecord>
        </transcript>
        <!--***************************************************************-->
        <!--************************************************SHE02_Structure-->
        <transcript>
            <exrefrecord>
               <recformat/>
               <recdata>Entry</recdata>
            </exrefrecord>
        </transcript>
        <!--***************************************************************-->
        <!--************************************************SHE03_Structure-->
        <identification>
            <ext_identification>
               <fieldlabel>
                   <typename>
                      <tyvalue>ISR_Nationality</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
            </ext_identification>
        </identification>
        <!--***************************************************************-->
        <!--************************************************SHE04_Structure-->
        <identification>
            <demographics>
               <uid>Entry</uid>
            </demographics>
        </identification>
        <!--***************************************************************-->
        <!--************************************************SHE05_Structure-->
        <activity>
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE06_Structure-->
        <identification>
            <address>
               <street>
                   <nonfieldedstreetaddress>Entry</nonfieldedstreetaddress>
               </street>
            </address>
        </identification>
        <!--***************************************************************-->
        <!--************************************************SHE07_Structure-->
        <activity>
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE09_Structure-->
        <activity>
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE10_Structure-->
        <activity>
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE11_Structure-->
        <activity>
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE12_Structure-->
        <activity>
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--************************************************SHE13_Structure-->
        <identification>
            <ext_identification>
               <fieldlabel>
                   <typename>
                      <tyvalue>ISR_FTE</tyvalue>
                   </typename>
               </fieldlabel>
               <fielddata>Entry</fielddata>
            </ext_identification>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q01_Structure-->
        <identification>
            <contentype>
               <referential>
                   <indexid>Entry</indexid>
               </referential>
            </contentype>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q02_Structure-->
        <activity>
            <learningactivityref>
               <sourcedid>
                   <source>FEFCISR</source>
                   <id>Entry</id>
               </sourcedid>
            </learningactivityref>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q05_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>TypeofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--*************************************************Q07A_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_AnnualFeesIndicator</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--*************************************************Q07B_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_TuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************Q08_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>NonpaymentofTuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************Q09_Structure-->
        <identification>
            <agent>
               <agentid>MajorSourceTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q10_Structure-->
        <identification>
            <agent>
               <agentid>CouncilorHEFCEFunding</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q11_Structure-->
        <identification>
            <agent>
               <agentid>MajorSourceOtherthanTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q12_Structure-->
        <identification>
            <agent>
               <agentid>MinorSourceOtherthanTuitionFees</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q13_Structure-->
        <identification>
            <agent>
               <agentid>FranchisedOutArrangements</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q15_Structure-->
        <activity>
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ExpectedGuidedLearningHours</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </unitsfield>
            </units>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q16_Structure-->
        <activity>
            <date>
               <datetime>Entry</datetime>
            </date>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q17_Structure-->
        <activity>
            <date>
               <datetime>Entry</datetime>
            </date>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q18_Structure-->
        <activity>
            <date>
               <datetime>Entry</datetime>
            </date>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q19_Structure-->
        <activity>
            <status>
               <description>
                   <short>Entry</short>
               </description>
            </status>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q20_Structure-->
        <activity>
            <evaluation>
               <result>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Outcome</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </score>
               </result>
            </evaluation>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q21_Structure-->
        <activity>
            <evaluation>
               <result>
                   <score>
                      <fieldlabel>
                          <typename>
                             <tyvalue>Grade</tyvalue>
                          </typename>
                      </fieldlabel>
                      <fielddata>Entry</fielddata>
                   </score>
               </result>
            </evaluation>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q22_Structure-->
        <activity>
            <evaluation>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </evaluation>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q24_Structure-->
        <ext_learnerinfo>
            <fieldlabel>
               <typename>
                   <tyvalue>ISR_Instspecificdataset</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
        </ext_learnerinfo>
        <!--***************************************************************-->
        <!--**************************************************Q25_Structure-->
        <ext_learnerinfo>
            <fieldlabel>
               <typename>
                   <tyvalue>ISR_Instspecificdataset</tyvalue>
               </typename>
            </fieldlabel>
            <fielddata>Entry</fielddata>
        </ext_learnerinfo>
        <!--***************************************************************-->
        <!--**************************************************Q26_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>NVQDeliveryArrangement</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************Q28_Structure-->
        <activity>
            <date>
               <datetime>Entry</datetime>
            </date>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q29_Structure-->
        <activity>
            <evaluation>
               <status>
                   <description>
                      <short>Entry</short>
                   </description>
               </status>
            </evaluation>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q30_Structure-->
        <activity>
            <learningactivityref>
               <sourcedid>
                   <source>FEFCISR</source>
                   <id>Entry</id>
               </sourcedid>
            </learningactivityref>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q31_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ImpliedRateforESFinQ11</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************Q32_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ImpliedRateforESFinQ12</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--**************************************************Q33_Structure-->
        <activity>
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>APLHours</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </unitsfield>
            </units>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q34_Structure-->
        <activity>
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q35_Structure-->
        <identification>
            <agent>
               <agentid>EmployerRole</agentid>
               <agentdomain/>
               <description>
                   <short>Entry</short>
               </description>
            </agent>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************Q36_Structure-->
        <activity>
            <definition>
               <description>
                   <short>Entry</short>
               </description>
            </definition>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************Q37_Structure-->
        <activity>
            <units>
               <unitsfield>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ActualGuidedLearningHours</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </unitsfield>
            </units>
        </activity>
        <!--***************************************************************-->
        <!--************************************************QHE01_Structure-->
        <accessibility>
            <eligibility>
               <ext_eligibility>
                   <fieldlabel>
                      <typename>
                          <tyvalue>ISR_TuitionFees</tyvalue>
                      </typename>
                   </fieldlabel>
                   <fielddata>Entry</fielddata>
               </ext_eligibility>
            </eligibility>
        </accessibility>
        <!--***************************************************************-->
        <!--************************************************QHE02_Structure-->
        <activity>
            <date>
               <datetime>Entry</datetime>
            </date>
        </activity>
        <!--***************************************************************-->
        <!--**************************************************E01_Structure-->
        <identification>
            <contentype>
               <referential>
                   <indexid>Entry</indexid>
               </referential>
            </contentype>
        </identification>
        <!--***************************************************************-->
        <!--**************************************************E02_Structure-->
        <qcl>
            <registrationno>Entry</registrationno>
        </qcl>
        <!--***************************************************************-->
        <!--**************************************************E03_Structure-->
        <qcl>
            <level>
               <text>Entry</text>
            </level>
        </qcl>
        <!--***************************************************************-->
        <!--**************************************************E04_Structure-->
        <qcl>
            <date>
               <datetime>Entry</datetime>
            </date>
        </qcl>
        <!--***************************************************************-->
     </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Advanced/isrmapv2_001/isrmapv2_001.xml

### 5.2.4 Key Features of the ISR Mapping Examples

The key features of these examples are:

- In Version 1 the different database entries are arranged in the greatest packing density e.g. the <identification> element contains thirteen fields (in Version 1 it would only contain a single field). This means that the field sequence is not maintained e.g. lines 28-40. The extension fields are accompanied by the usage of the <fieldlabel> element which is used to define the associated field structure number e.g. lines 77, 85, etc.);

- In Version 2 each separate ISR field is allocated its own core data structure object. This ensures that the order of the fields is maintained as per the ISR documentation. The ‘indexid’ feature is, in general’ not used as the sequence of the fields is predefined and maintained within the XML instance;

- In both Versions 1 and 2 the extension facilities are defined in a manner that avoids the usage of new elements i.e. the available set of elements are reused in a creative fashion.

The initial aim is to use subsets of the complete mapping for different exchange purposes e.g. enrolment data from an enrolment system to MIS, basic student and enrolment data to LMS/VLE, and data generated during learning that needs to be returned from the LMS/VLE to the MIS. For these purposes the order of the data is less important than minimising the transfers sizes and processing time, and so the first approach has been adopted. If in future the mapping were to be adopted for the transfer of the ISR records themselves from Colleges to the Funding Council, replacing the existing formnat for the benefits brought by using XML and XML Schema parsers, and other XML related software, then it may be desirable to adopt the second approach of maintaining the current sequence or the ISR fields.

# 6. IMS LIP and Other Relevant Specifications

## 6.1 IMS Specifications

### 6.1.1 Enterprise

The IMS LIP specification does NOT replace the IMS Enterprise specification. The two specifications are COMPLIMENTARY.

The scope of the IMS Enterprise specification is focused on defining interoperability between systems residing within the same enterprise or organization. Data exchange may be possible between separate enterprises, but the documents comprising the IMS Enterprise specification are not targeted at solving the issues of data integrity, communication, overall security, and others inherent when investigating cross-enterprise data exchange. The IMS Enterprise Information Model is designed to support interoperability for the following four business process components, which typically require interaction between Learning Management systems and these types of Enterprise systems:

- Personal Profile Data Maintenance – typically, data about people is maintained in the Enterprise systems, and is passed to the Learning Management environment. When this personal profile data changes in the Enterprise system, it needs to be updated in the Learning Management system;

- Group Management - group management processes can include data from class creation and class scheduling, and the ongoing maintenance of that data. A source system creates and maintains group information, which needs to be shared with other systems that are involved with group management functions. The flow of group management information is not necessarily one way; some data may be updated by a target system and passed back to the source system.

- Enrolment Management – enrolment management encompasses the initial creation of Group membership and various changes to that data over time. Examples of enrolment management include learner enrolment in courses and instructor assignment to courses;

- Final Result Processing – final result processing refers to the evaluation and recording of final group membership results (final grade, course completion, etc.). This processing can occur in the Learning Management systems or in the Enterprise system.

This model is supported through the use of three data objects, described briefly below:

- Person – this data object contains elements describing an individual of interest to the Learning Management environment;

- Group – this object contains elements describing a group of interest to the Learning Management environment. There are many types of groups that may be shared between systems. The most common is a Course Instance, but they may also include Training Programs, Academic Programs, Course sub-groups, clubs, etc. A group can also have any number of relationships with other groups;

- Group Membership – this data object contains elements describing the membership of a person or group within a group. Group members may be instructors, learners, content developers, members, managers, mentors, or administrators.

The salient points with respect to the relationship between the IMS LIP and IMS Enterprise specifications are:

- The IMS LIP specification should be used for the exchange of learner information. This means that the Personal Profile Data Maintenance features of the IMS Enterprise specification should be deprecated to the IMS LIP. The IMS LIP specification should also be used to exchange information about an organisation;

- All group memberships and group oriented information should be exchanged using the IMS Enterprise specification. The only membership information structures within the IMS LIP refer to the formal affiiations of a learner with a professional organisation. Group-based results should be exchanged using the IMS Enterprise specification whereas individual-based results should be exchanged using the IMS LIP specification.

### 6.1.2 Content Packaging

The IMS Content Packaging specification is to be used for the packaging of a LIP XML instance both in terms of a single learner instance and the the aggregation of several instances for a single learner or for multiple learners. Consider the following use-case required by the IMS LIP in which the LIP-XML instances for three learners are to be packaged:

- The sets of learner information have to be created i.e. in the files ‘learnerA.xml’, ‘learnerB.xml’ and ‘learnerB.xml. In each case the learner information has three associated files – a meta-data file and other material files (See Figure 6.1).

Figure 6.1 Schematic representation of the files to be packaged.

The issue becomes one of ensuring that when these three learner information sets are packaged together so that there are no name clashes between:

- The ‘photo.gif’ filers from learners A and C;

- The ‘hobby.doc’ files from learner B and C.

The IMS Content Packaging requires that all of the packaged files are uniquely named i.e. an explicit file directory structure has to be used to ensure that file clashes do not occur when creating the packaging manifest. The actual example is the XML used to refer to the ‘photo.gif’ files references in the XML instances for learner ‘A’ and ‘C’. The original partial XML could be of the form:

Learner A – original XML instance:

       <representation>

           <media mediamode="Image"mimetype="image/gif" encoding="uri">photo.gif</media>

       </representation>

Learner C – original XML instance:

       <representation>

           <media mediamode="Image"mimetype="image/gif" encoding="uri">photo.gif</media>

       </representation>

There are two ways to ensure that name clashes are avoided. The first is that whenever external linkages are made then the corresponding directory structure is also included. This would mean that the two examples above now become:

Learner A – modified XML instance:

       <representation>

           <media mediamode="Image"mimetype="image/gif" encoding="uri">learnerA/photo.gif

           </media>

       </representation>

Learner C – modified XML instance:

       <representation>

           <media mediamode="Image" mimetype="image/gif" encoding="uri">learnerC/photo.gif

           </media>

       </representation>

The two files now have different names and so no clash occurs. The name can include any level of directories. The issue now becomes one of ensuring that the directory structures ensure a uniquely named path. The same approach must now be adopted for the ‘hobby.doc’ references used in Figure 6.1. Alternatively, and the preferred approach, is to:

- In a Content Package create a sub-directory for each Learner with a unique name within the package;

- In that directory place the LIP instance and the associated portfolio files;

- If the portfolio files reference each other using relative sub-directories, then these should be maintained within the allocated sub-directory;

- References to portfolio files should be relative to their shared allocated sub-directory i.e. top-level references will only need to be preceeded by a slash but not directory name and existing relative sub-directory names are also used as defined;

- A resource element is used to specify the file name of the LIP instance and all the associated portfolio files;

- The xml:base attribute of the LIP’s resource element is used to specify the relative address of the allocated sub-directory.

### 6.1.3 Meta-data

There is NO meta-data as per the IMS Meta-data, IEEE LOM or Dublin Core definitions within the IMS LIP. The exchange of IMS LIP will be achieved through the packaging of the XML instance and all of its associated files using the IMS Content Packaging specification. This packaging specification includes the usage of meta-data. From an IMS LIP perspective the meta-data would normally be used to describe the packaging of the information e.g. the size of the file, the type of material include, etc. Therefore, the usage of the meta-data within the IMS Content Packaging specification is best and so no meta-data is included within the IMS LIP specification itself.

### 6.1.4 Accessibility

The IMS Accesibility working-group was incorporated in February 2001. Parts of the ‘accessibility core data structure will be modified when they release their V1.0 specification.

### 6.1.5 Competency Definitions

The IMS Competency Definition working-group was incorporated in August 2000. Parts of the ‘competency’ corer data structure will be amended appropriately when they release their V1.0 specification.

### 6.1.6 Question & Test Interoperability

Results summary information can be exchanged using the ‘activity’ core data structure within LIP. V1.2 of the IMS QTI specification will produce a more detailed results reporting mechanism; this version is timetabled for release in August 2001.

## 6.2 Other Specifications

### 6.2.1 IETF vCard

The IMS LIP is fully compatible with the IETF vCard specification i.e. all of the vCard fields can be contained by an LIP-XML instance. This relationship is shown in Table 6.1, namely:

Table 6.1 The usage of IMS LIP to support the IETF vCard specification.

vCard Element | IMS LIP Element(s) | Notes
FN | identification.fnme | The formatted name.
n | identification.name | The name.
family | identification.name.partname | The name with a typed partname entry.
given | identification.name.partname | The name with a typed partname entry.
other | identification.name.partname | The name with a typed partname entry.
prefix | identification.name.partname | The name with a typed partname entry.
suffix | identification.name.partname | The name with a typed partname entry.
nickname | identification.name.partname | The name with a typed partname entry.
photo | identification.demographics. representation.media | A photograph of the individual.
bday | identification.ext_identification | Requires the usage of the identification extension feature.
addr | identification.address | The address.
pobox | identification.address.pobox | The PO Box address component.
extadd | identification.address. nonfieldedstreetaddress | The extended address.
street | identification.address.street | The street address component.
locality | identification.address.locality | The locality address component.
region | identification.address.region | The region address component.
pcode | identification.address.postcode | The post code/zip code address component.
country | identification.address.county | The country address component.
label | identification.ext_identification | Requires the usage of the identification extension feature.
tel | identification.contactinfo. telephone | The telephone number.
email | identification.contactinfo.email | The email address.
mailer | identification.ext_identification | Requires the usage of the identification extension feature.
tz | identification.address.timezone | The time zone address component.
geo | identification.address.geo | The geographical location address component.
lat | identification.address.geo.lat | The latitude location address component.
lon | identification.address.geo.lon | The longitude location address component.
title | affiliation.organisation.role | The title of the individual in their organisation.
role | affiliation.organisation.role | The individual’s role in their organisation
logo | affiliation.description.full.media | A organisation’s logo.
agent | identification.agent | Authorised agent representative for the individual.
org | affiliation.organisation | Details of the individuals host organisation.
categories | learnerinformation.ext_learnerinfo | Requires the usage of the learnerinformation extension feature.
item | learnerinformation.ext_learnerinfo | Requires the usage of the learnerinformation extension feature.
note | learnerinformation.comment | Could be supported in any of the IMS LIP comment elements.
sort | identification.name.partname | This will require the usage of the extension of the partname voicabulary.
sound | identification.demographics. representation.media | An audio representation of the individual.
url | identification.contactinfo.web | The web URL.
key | securitykey.keyfields | Security keys.

Note that the information shown in Table 6.1. describes one possible relationship. Others are possible. It is our intention to show that at least way in which the IMS LIP can be used to contain the vCard information (the inverse is not possible as vCard is designed to act as an electronic business card only).

### 6.2.2 IEEE PAPI

The development of the IMS LIP incorporated the work undertaken on the IEEE PAPI. The relationship between the IEEE PAPI and the IMS LIP is shown schematically in Figure 6.2.

Figure 6.2 The usage of IMS LIP to support IEEE PAPI.

The ways in which eleven core data structures of the IMS LIP can contain the information of the six structures that underpin the IEEE PAPI are denoted by the arrows. A more detailed mapping is not currently possible because at presnt there is no binding for the IEEE PAPI.

### 6.2.3 Internet2/Educase ‘eduPerson’

The eduParson specification is an obect class for LDAP services whereas LIP is a set of data objects for the exchange of learner information and not just directory-related information. The relationship between the eduPerson V1.0 specification and the IMS LIP V1.0 is summarised in Table 6.2.

Table 6.2 The usage of IMS LIP to exchange the eduPerson information

EduPerson Object Definition | IMS LIP Data Structure | Comments
EduPersonAffiliation (OID: 1.3.6.1.4.1.5923.1.1.1.1) | affiliation.classification | Specifies the person’s relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. This is to use a controlled vocabulary and IMS will work with Internet2/Educause to achieve a common vocabulary base.
EduPersonNickname (OID: 1.3.6.1.4.1.5923.1.1.1.2) | identification.name or identification.formname | Person’s nickname, or the informal name by which they are accustomed to be hailed. This can be contained in either of two LIP data structures both within the <identification> element.
EduPersonOrgDN (OID: 1.3.6.1.4.1.5923.1.1.1.3) | affiliation.organization | The distinguished name (DN) of the directory entry representing the institution with which the person is associated. The organization structure within the <affiliation> element can be used to store this identifier.
EduPersonOrgUnitDN (OID: 1.3.6.1.4.1.5923.1.1.1.4) | affiliation.organization | The distinguished name (DN) of the directory entries representing the person’s Organizational Unit(s). With a distinguished name, the client can do an efficient lookup in the institution’s directory for information about the person's organizational unit(s).
EduPersonPrimaryAffiliation (OID: 1.3.6.1.4.1.5923.1.1.1.5) | affiliation.classification | Specifies the person’s PRIMARY relationship to the institution in broad categories such as student, faculty, staff, alum, etc. This is to use a controlled vocabulary and IMS will work with Internet2/Educause to achieve a common vocabulary base.
EduPersonPrincipalName (OID: 1.3.6.1.4.1.5923.1.1.1.6) | identification.name or identification.formname or identification.contactinfo.email | The "NetID" of the person for the purposes of inter-institutional authentication. Should be stored in the form of user@univ.edu, where univ.edu is the name of the local security domain. This information can be supported within LIP using one of three structures all within the <identification> element.

It is recommended that when the LIP is used to exchange the eduPerson information that the appropriate ‘indexid’ references are used to contain either the OID or the name of the eduPerson object. This gives rise to:

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     <learnerinformation>
        <comment>eduPerson exchange</comment>
        <identification>
            </contentype>
            <name>
               <contentype>
                   <referential>
                      <indexid>OID:1.3.6.1.4.1.5923.1.1.1.2</indexid>
                   </referential>
               </contentype>
               <partname>
                   <text>Entry</text>
               </partname>
            </name>
            <contactinfo>
               <contentype>
                   <referential>
                      <indexid> ID:1.3.6.1.4.1.5923.1.1.1.6</indexid>
                   </referential>
               </contentype>
               <email>Entry</email>
            </contactinfo>
        </identification>
        <affiliation>
            <contentype>
               <referential>
                   <indexid>OID:1.3.6.1.4.1.5923.1.1.1.1</indexid>
               </referential>
            </contentype>
            <classification>Entry</classification>
        </affiliation>
        <affiliation>
            <contentype>
               <referential>
                   <indexid>OID:1.3.6.1.4.1.5923.1.1.1.5</indexid>
               </referential>
            </contentype>
            <classification>Entry</classification>
        </affiliation>
        <affiliation>
            <contentype>
               <referential>
                   <indexid>OID:1.3.6.1.4.1.5923.1.1.1.3</indexid>
               </referential>
            </contentype>
            <organization>
               <description>
                   <short>Entry</short>
               </description>
            </organization>
        <affiliation>
            <contentype>
               <referential>
                   <indexid>OID:1.3.6.1.4.1.5923.1.1.1.4</indexid>
               </referential>
            </contentype>
            <organization>
               <description>
                   <short>Entry</short>
               </description>
            </organization>
     </learnerinformation>

# 7. Implementation Guidance

## 7.1 Nomenclature

The LIP specification supports the exchange of learner information among learning management systems, human resource systems, student information systems, enterprise e-learning systems, knowledge management systems, resume repositories, and other systems used in the learning process. Such systems will be called learner information systems regardless of any other functionality they possess or roles they fulfil. The IMS Learner Information Package specification does not address requests for learner information or the exchange transaction mechanism. It is important to note that:

- The LIP is concerned with the interoperability for the exchange of learner information between communicating LIP systems. It makes no comment on how the data should be stored in the communicating systems once the exchange has occurred;

- The LIP specification contains the description of the data model for the learner information. It does not address behavioural models for the learner information nor does it describe the mechanisms used for the electronic exchange the information;

- The LIP data model is incomplete. It was not created to be a definitive model of all the possible information that could be exchanged between LIP systems. Instead it describes many of the common data structures and provides several extension features (see Section 9) that can be used to tailor the LIP for a particular implementation.

## 7.2 Using the Core Data Structures

### 7.2.1 <accessibility>

The accessibility learner information consists of the cognitive, technical and physical preferences for the learner, disability, eligibility and language capabilities. These describe the learner’s capabilities to interact with the learning environment. The accessibility data structure is complex in that it consists of four other sub-data structures any one of which can be supplied independently of the others. The minimum XML-instance for an accessibility data structure is:

       <accessibility>

           <language>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>German</tyvalue>

              </typename>

              <proficiency profmode="Write">Poor</proficiency>

           </language>

           <preference>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>InputTech</tyvalue>

              </typename>

              <prefcode>Large Font Display Devices</prefcode>

           </preference>

       </accessibility>

Note that the type of language and preference should be supplied otherwise the information is nonsensical. The maximal form of a useful accessibility structure is (this ignores the eligibility and disability data structures that are for further study as part of the IMS Accessibility working-group’s activities):

       <accessibility>

           <contentype>

              <referential>

                  <indexid>accessibility_01</indexid>

              </referential>

           </contentype>

           <language>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>German</tyvalue>

           </typename>

              <comment>-----------------------------------------Language</comment>

              <contentype>

                  <referential>

                     <indexid>language_01</indexid>

                  </referential>

              </contentype>

              <proficiency profmode="OralSpeak">Excellent</proficiency>

              <proficiency profmode="OralComp">Excellent</proficiency>

              <proficiency profmode="Read">Good</proficiency>

              <proficiency profmode="Write">Poor</proficiency>

           </language>

           <preference>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>InputTech</tyvalue>

              </typename>

              <comment>---------------------------------------Preference</comment>

              <contentype>

                  <referential>

                     <indexid>preference_01</indexid>

                  </referential>

              </contentype>

              <prefcode>Large Font Display Devices</prefcode>

           </preference>

       </accessibility>

More information concerning this example is given in Section 4.1.

### 7.2.2 <activity>

The activity learner information consists of the education/training, work and service (military, community, voluntary, etc.) record and products (excluding formal awards). This information may include the descriptions of the courses undertaken and the records of the corresponding assessment. A separate activity structure will be used for each entry. The activity data structure is complex in that it consists of several other sub-data structures any one of which can be supplied independently of the others. The minimum complete XML-instance for an activity data structure is:

       <activity>

           <units>

              <unitsfield>

                  <fieldlabel>

                     <typename>

                         <tyvalue>CreditNumber</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>10</fielddata>

              </unitsfield>

           </units>

           <learningactivityref>

              <text>Degree in Philiosphy</text>

           </learningactivityref>

           <definition>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Curriculum</tyvalue>

              </typename>

              <definitionfield>

                  <fieldlabel>

                     <typename>

                         <tyvalue>Duration</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>3</fielddata>

              </definitionfield>

           </definition>

           <product>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Coursework</tyvalue>

              </typename>

              <description>

                  <short>Thesis on violins</short>

                 <full>

                     <media mediamode="Text" mimetype="text/word" contentreftype="uri">

                         sh/thesis.doc

                     </media>

                  </full>

              </description>

           </product>

           <testimonial>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Academic</tyvalue>

              </typename>

              <description>

                  <short>Tutors reference</short>

                  <full>

                     <media mediamode="Text" mimetype="text/word" contentreftype="uri">

                         tutor/ref.doc

                     </media>

                  </full>

              </description>

           </testimonial>

           <evaluation>

              <result>

                  <score>

                     <fieldlabel>

                         <typename>

                            <tyvalue>Total</tyvalue>

                         </typename>

                     </fieldlabel>

                     <fielddata>80</fielddata>

                  </score>

              </result>

           </evaluation>

       </activity>

The maximal form of a useful activity structure is:

       <activity>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Education</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>activity_1</indexid>

              </referential>

           </contentype>

           <date>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Award</tyvalue>

              </typename>

              <datetime>1919:7</datetime>

           </date>

           <status>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Completed</tyvalue>

              </typename>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Finish</tyvalue>

                  </typename>

                  <datetime>1919:6</datetime>

              </date>

           </status>

           <units>

              <unitsfield>

                  <fieldlabel>

                     <typename>

                         <tyvalue>CreditNumber</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>10</fielddata>

              </unitsfield>

           </units>

           <learningactivityref>

              <text>Degree in Philiosphy</text>

           </learningactivityref>

           <definition>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Curriculum</tyvalue>

              </typename>

              <contentype>

                  <referential>

                     <indexid>degreecourse</indexid>

                  </referential>

              </contentype>

              <definitionfield>

                  <fieldlabel>

                     <typename>

                         <tyvalue>Duration</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>3</fielddata>

              </definitionfield>

           </definition>

           <product>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Coursework</tyvalue>

              </typename>

              <contentype>

                  <referential>

                     <indexid>activity_product_01</indexid>

                  </referential>

              </contentype>

              <description>

                  <short>Thesis on violins</short>

                  <full>

                     <media mediamode="Text" mimetype="text/word" contentreftype="uri">

                         sh/thesis.doc

                     </media>

                  </full>

              </description>

           </product>

           <testimonial>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Academic</tyvalue>

              </typename>

              <contentype>

                  <referential>

                     <indexid>activity_testimonial_01</indexid>

                  </referential>

              </contentype>

              <description>

                  <short>Tutors reference</short>

                  <full>

                     <media mediamode="Text" mimetype="text/word" contentreftype="uri">

                         tutor/ref.doc

                     </media>

                  </full>

              </description>

           </testimonial>

           <evaluation>

              <contentype>

                  <referential>

                     <indexid>activity_evaluation_01</indexid>

                  </referential>

              </contentype>

              <result>

                  <interpretscore>

                     <fieldlabel>

                         <typename>

                            <tyvalue>MinScore</tyvalue>

                         </typename>

                     </fieldlabel>

                     <fielddata>0</fielddata>

                  </interpretscore>

                  <interpretscore>

                     <fieldlabel>

                         <typename>

                            <tyvalue>MaxScore</tyvalue>

                         </typename>

                     </fieldlabel>

                     <fielddata>100</fielddata>

                  </interpretscore>

                  <score>

                     <fieldlabel>

                         <typename>

                            <tyvalue>Total</tyvalue>

                         </typename>

                     </fieldlabel>

                     <fielddata>80</fielddata>

                  </score>

              </result>

           </evaluation>

           <description>

              <short>Final degree information.</short>

           </description>

       </activity>

More information concerning this example is given in Section 4.2.

### 7.2.3 <affiliation>

The affiliation learner information is used to store the descriptions of the organisation affiliations associated with the learner. These affiliations may include education groups e.g. classes, cohorts, etc. but it is expected that these will be exchanged using the IMS Enterprise specification technique. The minimum XML-instance for an affiliation is:

       <affiliation>

           <classification>Fellow</classification>

           <affiliationid>2457923A</affiliationid>

           <organization>

              <description>

                  <short>Royal Institution of Criminology: London Branch</short>

              </description>

           </organization>

       </affiliation>

The maximal form of a useful affiliation structure is (this includes information concerning the role within the organisation to which the learner is affiliated):

       <affiliation>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Professional</tyvalue>

           </typename>

           <classification>Fellow</classification>

           <affiliationid>2457923A</affiliationid>

           <role>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Officer</tyvalue>

              </typename>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Start</tyvalue>

                  </typename>

                  <datetime>1924:04:01</datetime>

              </date>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Finish</tyvalue>

                  </typename>

                  <datetime>1925:03:31</datetime>

              </date>

              <description>

                  <short>Treasurer for the Local Branch of Criminology</short>

              </description>

           </role>

           <organization>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Professional</tyvalue>

              </typename>

              <description>

                  <short>Royal Academy</short>

              </description>

           </organization>

           <date>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Join</tyvalue>

              </typename>

              <datetime>1922</datetime>

           </date>

           <status>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Active</tyvalue>

              </typename>

           </status>

           <description>

              <short>All fees paid</short>

           </description>

       </affiliation>

More information concerning this example is given in Section 4.3.

### 7.2.4 <competency

The competency learner information consists of the descriptions of the skills the learner has acquired. These skills may be associated with some formal or informal training or work history (described in the ‘activity’) and formal awards (described in the ‘qcl’). A different ‘competency’ structure will be used for each competency through an external reference mechanism. The adopted competency definition will be amended to follow the work of the IMS Competency Definition working-group when that specification is completed. The minimum form of a useful competency structure is:

       <competency>

           <exrefrecord>

              <recformat>MSWord</recformat>

              <recdata uri="filename.doc"/>

           </exrefrecord>

       </competency>

The possible entries within the recformat element are undefined but the associated entry within the recdata element should be consistent with it (cf. the transcript element). Note that the competency structure has no typename element. This is because, until the IMS Competency Definition work is completed, we could find no appropriate typing of the competency. The maximal form of a useful competency structure is:

       <competency>

           <contentype>

              <referential>

                  <indexid>competency_01</indexid>

              </referential>

           </contentype>

           <exrefrecord>

              <recformat uri="compformats/criminology.doc"/>

              <recdata uri="holmes/competency.doc"/>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Award</tyvalue>

                  </typename>

                  <datetime>1927:10:21</datetime>

              </date>

           </exrefrecord>

           <description>

              <short>Competencies in Criminology</short>

           </description>

       </competency>

More information concerning this example is given in Section 4.4.

### 7.2.5 <goal>

The goal learner information consists of the description of the personal objectives and aspirations. These descriptions may also include information for monitoring the progress in achieving the goals. A goal can be defined in terms of sub-goals. A different goal structure will be used for each entry. The minimum XML-instance for a goal is:

       <goal>

           <description>

              <short>To graduate</short>

              <full>

                  <media mediamode="Text" mimetype="text/base" contentreftype="uri">lifeplan.doc

                  </media>

              </full>

           </description>

       </goal>

The maximum contents for a goal XML-instance is (this example contains a sub-goal):

       <goal>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Work</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>goal_01</indexid>

              </referential>

           </contentype>

           <date>

              <typename>

                 <tysource sourcetype="imsdefault"/>

                  <tyvalue>Start</tyvalue>

              </typename>

              <datetime>1925</datetime>

           </date>

           <priority>Primary Objective</priority>

           <status>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Active</tyvalue>

              </typename>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Create</tyvalue>

                  </typename>

                  <datetime>1926:3:30</datetime>

              </date>

           </status>

           <description>

              <short>To arrest Moriarty</short>

              <full>

                  <media mediamode="Image" mimetype="image/gif" contentreftype="uri">

                     sh/moriarty.gif

                  </media>

              </full>

           </description>

           <goal>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Work</tyvalue>

              </typename>

              <contentype>

                  <referential>

                     <indexid>goal_01_subgoal_02</indexid>

                  </referential>

              </contentype>

              <description>

                  <short>Train Watson to be a competent detective.</short>

              </description>

           </goal>

       </goal>

More information concerning this example is given in Section 4.5.

### 7.2.6 <identification>

The identification learner information contains all of the data for a specific individual or organisation. This includes data such as: name, address, contact information, agent and demographics. The identification data structure is complex in that it consists of several other sub-data structures any one of which can be supplied independently of the others. The minimum complete XML-instance for an identification data structure is:

       <identification>

           <formname>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Preferred</tyvalue>

              </typename>

              <text>Mr Sherlock Holmes</text>

           </formname>

           <name>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Preferred</tyvalue>

              </typename>

              <partname>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Last</tyvalue>

                  </typename>

                  <text>Holmes</text>

              </partname>

           </name>

           <address>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Permanent</tyvalue>

              </typename>

              <street>

                  <streetname>Baker Street</streetname>

                  <aptnumber>22</aptnumber>

                  <aptnumsuffix>b</aptnumsuffix>

              </street>

              <city>London</city>

              <country>England</country>

           </address>

           <contactinfo>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Private</tyvalue>

              </typename>

              <telephone>

                  <countrycode>44</countrycode>

                  <areacode>020</areacode>

                  <indnumber>6472239</indnumber>

              </telephone>

           </contactinfo>

           <demographics>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Adult</tyvalue>

              </typename>

              <gender gender="M"/>

           </demographics>

           <agent>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Aide</tyvalue>

              </typename>

              <agentid>Dr.Watson</agentid>

              <agentdomain>

                 <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Medical</tyvalue>

                  </typename>

              </agentdomain>

           </agent>

       </identification>

The maximal complete form of a useful identification structure is:

       <identification>

           <comment>-----------------------------------------Identification</comment>

           <contentype>

              <referential>

                  <indexid>identification_01</indexid>

              </referential>

           </contentype>

           <formname>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Preferred</tyvalue>

              </typename>

              <comment>--------------------------Formatted Name details</comment>

              <contentype>

                  <referential>

                     <indexid>formname_01</indexid>

                  </referential>

              </contentype>

              <text>Mr Sherlock Holmes</text>

           </formname>

           <name>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Preferred</tyvalue>

              </typename>

              <comment>-------------------------------------Name details</comment>

              <contentype>

                  <referential>

                     <indexid>name_01</indexid>

                  </referential>

              </contentype>

              <partname>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>First</tyvalue>

                  </typename>

                  <text>Sherlock</text>

              </partname>

              <partname>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Last</tyvalue>

                  </typename>

                  <text>Holmes</text>

              </partname>

           </name>

           <address>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Permanent</tyvalue>

              </typename>

              <comment>---------------------------------Address details</comment>

              <contentype>

                  <referential>

                     <indexid>address_01</indexid>

                  </referential>

              </contentype>

              <street>

                  <streetname>Baker Street</streetname>

                  <aptnumber>22</aptnumber>

                  <aptnumsuffix>b</aptnumsuffix>

              </street>

              <city>London</city>

              <country>England</country>

           </address>

           <contactinfo>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Private</tyvalue>

              </typename>

              <comment>----------------------------------Contact details</comment>

              <contentype>

                  <referential>

                     <indexid>contactinfo_01</indexid>

                  </referential>

              </contentype>

              <telephone>

                  <countrycode>44</countrycode>

                  <areacode>020</areacode>

                  <indnumber>6472239</indnumber>

              </telephone>

           </contactinfo>

           <demographics>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Adult</tyvalue>

              </typename>

              <comment>------------------------------Demographic details</comment>

              <contentype>

                  <referential>

                     <indexid>demographics_01</indexid>

                  </referential>

              </contentype>

              <gender gender="M"/>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Birth</tyvalue>

                  </typename>

                  <datetime>1901:04:01</datetime>

              </date>

           </demographics>

           <agent>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Aide</tyvalue>

              </typename>

              <comment>------------------------------------Agent details</comment>

              <contentype>

                  <referential>

                     <indexid>agent_01</indexid>

                  </referential>

              </contentype>

              <agentid>Dr.Watson</agentid>

              <agentdomain>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Medical</tyvalue>

                  </typename>

              </agentdomain>

           </agent>

       </identification>

More information concerning this example is given in Section 4.6.

### 7.2.7 <interest>

The interest learner information consists of descriptions of hobbies and other recreational activities. These interests may have formal awards (as described in the associated ‘qcl’). Electronic versions of the products of these interests may also be contained. Each interest will be described within its own interest structure. The minimum XML-instance for an interest is:

       <interest>

           <product>

              <description>

                  <full>

                     <media mediamode="Text" mimetype="text/base" contentreftype="uri">file.txt

                     </media>

                  </full>

              </description>

           </product>

       </interest>

The maximal form of a useful interest structure is:

       <interest>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Recreational</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>interest_01</indexid>

              </referential>

           </contentype>

           <product>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Portfolio</tyvalue>

              </typename>

              <contentype>

                  <referential>

                     <indexid>product_01</indexid>

                  </referential>

              </contentype>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Create</tyvalue>

                  </typename>

                  <datetime>1928:10:21</datetime>

              </date>

              <description>

                  <full>

                     <media mediamode="Text" mimetype="text/base" contentreftype="uri">file.txt

                     </media>

                  </full>

              </description>

           </product>

           <description>

              <short>Favourite hobby.</short>

           </description>

       </interest>

More information concerning this example is given in Section 4.7.

### 7.2.8 <qcl>

The qcl learner information consists of the qualifications, certifications and licenses awarded to the learner i.e. the formally recognised products of their learning and work history. This includes information on the awarding body and may also include electronic copies of the actual documents. A different qcl structure will be used for each qualification, etc. The minimum XML-instance for a qcl is:

       <qcl>

           <title>Physics</title>

           <organization>

              <description>

                  <short>Princeton University</short>

              </description>

           </organization>

          <level>

              <text>Honours</text>

           </level>

       </qcl>

The maximal form of a useful qcl structure is:

       <qcl>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Qualification</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>qcl_01</indexid>

              </referential>

           </contentype>

           <title>MA Criminology</title>

           <organization>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Educational</tyvalue>

              </typename>

              <description>

                  <short>Cambridge University</short>

              </description>

           </organization>

           <level>

              <text>First Class Honours</text>

           </level>

           <date>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Award</tyvalue>

              </typename>

              <datetime>1920</datetime>

           </date>

           <description>

              <full>

                  <media mediamode="Image" mimetype="image/gif" contentreftype="uri">

                     holmes/degree.gif

                  </media>

              </full>

           </description>

       </qcl>

More information concerning this example is given in Section 4.8.

### 7.2.9 <relationship>

The relationship learner information is used to store the description of the relations between the other core data structures. All of the relationship information has been removed from the other structures to enable these to be collected at a single place. This structure may also be used to describe mapping relationships to be used by the communicating systems. The minimum XML-instance for a relationship is:

       <relationship>

           <tuple>

              <tuplesource>

                  <indexid>qcl_01</indexid>

              </tuplesource>

              <tuplerelation>

                  <typename>

                     <tyvalue>results_from</tyvalue>

                  </typename>

              </tuplerelation>

              <tupledest>

                  <indexid>transcript_01</indexid>

              </tupledest>

           </tuple>

       </relationship>

In this example a relationship between a ‘qcl’ (the absence of a sourcedid means that the record was previously associated with this learner information) is created with a transcript (also previously associated with this learner information). The maximal form of a useful relationship structure is:

       <relationship>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Qcl</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>relationship_01</indexid>

              </referential>

           </contentype>

           <tuple>

              <tuplesource>

                  <sourcedid>

                     <source>IMS_LIP_V1p0_Example</source>

                     <id>1001</id>

                  </sourcedid>

                  <indexid>qcl_01</indexid>

              </tuplesource>

              <tuplerelation>

                  <typename>

                     <tyvalue>results_from</tyvalue>

                  </typename>

              </tuplerelation>

              <tupledest>

                  <sourcedid>

                     <source>IMS_LIP_V1p0_Example</source>

                     <id>1001</id>

                  </sourcedid>

                  <indexid>transcript_01</indexid>

              </tupledest>

           </tuple>

           <description>

              <short>The QCL was based upon the identified transcript.</short>

           </description>

       </relationship>

More information concerning this example is given in Section 4.9.

### 7.2.10 <securitykey>

The securitykey learner information is used to store the passwords and security codes that are to be used when communicating with the learner. A different securitykey structure will be used for each key and class of key. The minimum XML-instance for a securitykey is:

       <securitykey>

           <keyfields>

              <fieldlabel>

                  <typename>

                     <tyvalue>PersonalPassword</tyvalue>

                  </typename>

              </fieldlabel>

              <fielddata>asits9</fielddata>

           </keyfields>

       </securitykey>

The maximal form of a useful securitykey structure is:

       <securitykey>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Password</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>securitykey_1</indexid>

              </referential>

           </contentype>

           <keyfields>

              <fieldlabel>

                  <typename>

                     <tyvalue>PersonalPassword</tyvalue>

                  </typename>

              </fieldlabel>

              <fielddata>asits9</fielddata>

           </keyfields>

           <keyfields>

              <fieldlabel>

                  <typename>

                     <tyvalue>LMSPassword</tyvalue>

                  </typename>

              </fieldlabel>

              <fielddata>moriarty</fielddata>

           </keyfields>

       </securitykey>

More information concerning this example is given in Section 4.10.

### 7.2.11 <transcript>

The transcript learner information is used to store the summary records of the academic performance at an institution. This information may contain an arbitrary level of detail and so there is no proscribed structure for a transcript. The minimum form of a useful transcript structure is:

       <transcript>

           <exrefrecord>

              <recformat>MSWord98</recformat>

              <recdata uri="holmes/cambridge_degree.doc"/>

           </exrefrecord>

       </transcript>

The possible entries within the recformat element are undefined but the associated entry within the recdata element should be consistent with it (cf. the competency element). The maximal form of a useful transcript structure is:

       <transcript>

           <typename>

              <tysource sourcetype="imsdefault"/>

              <tyvalue>Academic</tyvalue>

           </typename>

           <contentype>

              <referential>

                  <indexid>transcript_01</indexid>

              </referential>

           </contentype>

           <exrefrecord>

              <recformat>MSWord98</recformat>

              <recdata uri="holmes/cambridge_degree.doc"/>

              <date>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Award</tyvalue>

              </typename>

                  <datetime>1920:9:30</datetime>

              </date>

           </exrefrecord>

           <description>

              <short>Cambridge University Transcript</short>

           </description>

       </transcript>

More information concerning this example is given in Section 4.11.

## 7.3 LIP Structural Meta-data

The information model contains both data and meta-data about that data. The model defines fields into which the data can be placed and the type of data that may be put into these fields. Typical data might be the name of a learner, a course or training completed, a learning objective, a preference for a particular type of technology, and so on. Meta-data (this has nothing to with the IMS Meta-data specification et al) about each field can include:

- Referential – the information structure that can be used to contain the data that uniquely identifies the data itself;

- Temporal – the information structure that can be used to contain time-based data about the data itself e.g. the date of creation of the data;

- Privacy – the information structure that can be used to contain privacy data (such as access control rights) and to ensure the integrity of the data e.g. a checksums.

### 7.3.1 Referential Structure

The referential information is used to uniquely identify the learner information record as a whole and the individual data components within that record. These enable each piece of information to be identified. The actual identification system is outside the scope of this specification. The referential system is based upon the use of sourcedids and indexids (see Section 7.6).

### 7.3.2 Temporal Structure

This information is used to describe any time-based dependencies of the data. This includes information such as the date of creation, time-stamp and expiry date of the learner information. The date/time descriptions are expected to conform to the ISO8601 standard and are based upon the date element. An example of the temporal structure is:

       <contentype>

           <temporal>

              <temporalfield>

                  <fieldlabel>

                     <typename

                         <tyvalue>Creation</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>2000:12:31T17:00:00</fielddata>

              </temporalfield>

              <temporalfield>

                  <fieldlabel>

                     <typename

                         <tyvalue>Expiry</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>2001:12:31T17:00:00</fielddata>

              </temporalfield>

              <temporalfield>

                  <fieldlabel>

                     <typename

                         <tyvalue>Deletion</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>2002:12:31T17:00:00</fielddata>

              </temporalfield>

           </temporal>

       </contentype>

In this example the associated data structure has a defined creation, expiry and deletion data/time. The ways in which this information is stored within the communicating systems is beyond the scope of the LIP specification.

### 7.3.3 Privacy Structure

All of the data relevant to the privacy, authenticity and integrity of the learner information is contained within this structure. The actual privacy etc. mechanism and architectures used to support the learner information are outside of the scope of the specification but they interact with the learner information through these structures. An example of the privacy structure is:

       <contentype>

           <privacy>

              <typename>

                  <tysource sourcetype="imsdefault"/>

                  <tyvalue>Owner</tyvalue>

              </typename>

              <privacyfield>

                  <fieldlabel>

                     <typename

                         <tyvalue>Access</tyvalue>

                     </typename>

                  </fieldlabel>

                  <fielddata>Delete,Read,Write</fielddata>

              </privacyfield>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Create</tyvalue>

                  </typename>

                  <datetime>2000:12:31</datetime>

              <date>

              <date>

                  <typename>

                     <tysource sourcetype="imsdefault"/>

                     <tyvalue>Expiry</tyvalue>

                  </typename>

                  <datetime>2001:06:30</datetime>

              <date>

           </privacy>

       </contentype>

In this example the associated data structure has a defined a privacy mechanism to be applied to the data structure with respect to the ‘Owner’ of the data. This defines the access rights as write, delete and read. The privacy instructions are defined as valid between the date of creation and the date of expiry.

## 7.4 The LIP Vocabularies

During the development of the LIP there was a great deal of discussion concerning the contents and structure of the LIP vocabularies. The vocabularies are used in three ways:

- To define the content of data structure e.g. to mark an address as the referring to the ‘billing’, ‘mailing’, etc;

- To define the type of a data structure e.g. to mark activity as referring to ‘work’, ‘service’, etc. activities. This technique was used to allow us to create a more concise information model;

- To define the label of a data entry e.g. for the results element which is composed of a user defined data structure.

### 7.4.1 The Basic Vocabularies

Thirty one vocabularies have been identified and these are listed in Table 7.1 of the LIP Information Model [LIP, 01a]. The contents of these vocabularies are not definitive and we seek recommendations for their extension and amendment. In particular, these vocabularies are to be inclusive and we are not seeking to produce the definitive entry for each possible entry within the vocabulary i.e. we are willing to have more than one entry referring to a particular type of data e.g. for part names we have ‘last’ and ‘surname’.

The type of vocabulary is defined using the sourcetype attribute with the tysource element. The sourcetype attribute defines four ways in which vocabularies can be referenced: an included list, using the IMS default, using an externally referenced proprietary vocabulary and as an externally referenced standardised vocabulary.

#### Explicit List

An example of the inclusion of an explicit list is:

       <affiliation>

           <typename

              <tysource sourcetype=”List”>IEEE,ACM,BCS,IEE</tysource>

              <tyvalue>ACM</tyvalue>

           </typename>

           …

       </affiliation>

In this example the list given in the tysource element defines the set of possible affiliations and the data content for the tyvalue element shows the selected entry. It is undefined whether or not the list created in this manner is an extension to the default IMS vocabulary for affiliations. The validation of the selected entry against the given vocabulary list must be performed by some data validation system as it cannot be supported by the XML parsers.

#### IMS Default

An example of the usage of the default IMS vocabularies is:

       <affiliation>

           <typename

              <tysource sourcetype=”imsdefault”/>

              <tyvalue>Professional</tyvalue>

           </typename>

           …

       </affiliation>

In this example the tysource element indicates that the default IMS vocabularies are to be used (the fact that the affiliation vocabulary is to be used is taken from the context of the usage of the typename element). It should be noted that the specification does not define how the systems and their parsers obtain the actual default vocabularies as these are not defined with in XML Schema or the XML instances. It is assumed that the system has access to these vocabularies and that the data is validated against these vocabularies using some internal data validation mechanism i.e. the XML parser does not perform this validation. If necessary it may be possible to pass the default file name to be used i.e.

       <affiliation>

           <typename

              <tysource sourcetype=”imsdefault”>imsdefaultdirectory/imsdefaultfilename.txt

              </tysource>

              <tyvalue>Professional</tyvalue>

           </typename>

           …

       </affiliation>

or an extension to the default vocabulary could be supported by:

       <affiliation>

           <typename

              <tysource sourcetype=”imsdefault”>IEEE,ACM,BCS,IEE</tysource>

              <tyvalue>Professional</tyvalue>

           </typename>

           …

       </affiliation>

The operation of the system is undefined for both of these techniques. It is of interest to know if early adopters wish to make use of these latter extensions to the usage of the default IMS vocabularies.

#### Proprietary

An example of the usage of the proprietary vocabularies is:

       <affiliation>

           <typename

              <tysource sourcetype=”proprietary”>directory/filename.txt</tysource>

              <tyvalue>IEEE</tyvalue>

           </typename>

           …

       </affiliation>

In this example the file name of the proprietary vocabulary has been given however an alternative method is to pass a logical identifier for the vocabulary e.g.

       <affiliation>

           <typename

              <tysource sourcetype=”proprietary”>affiliationvocab1</tysource>

              <tyvalue>IEEE</tyvalue>

           </typename>

           …

       </affiliation>

It is assumed that the selected entry from the vocabulary is contained within the proprietary vocabulary. The proprietary vocabularies make contain some or all of the entries contained within the default IMS vocabularies. The key difference is that IMS has no responsibility for the maintenance of the proprietary vocabularies.

#### Standardised

The standardised vocabularies are assumed to be controlled by some appropriate external standards and/or specifications organisation i.e. the IEEE, ISO, etc. An example of this approach is:

       <affiliation>

           <typename

              <tysource sourcetype=”standard”>ISO</tysource>

              <tyvalue>IEEE</tyvalue>

           </typename>

           …

       </affiliation>

The possible identifiers for the content of the tysource element are undefined. At present no externally standardised vocabularies have been identified. Recommendations for such vocabularies are requested so that we can establish an appropriate mnemonic to be supplied as the content of the tysource element.

### 7.4.2 Extending the Vocabularies

The vocabularies can be extended by:

- Owners of the proprietary extensions can make additions as and when required;

- IMS will make additions to their default vocabularies in a controlled fashion. Such amendments will take place subject to the agreement of the IMS Technical Board and will be accompanied by the corresponding changes in the LIP Information Model. At some point the vocabularies may be defined as a series of independent XML instances with the appropriate version control information;

- The organisations responsible for the standard vocabularies will make the necessary changes using their own agreed mechanisms.

It is recommended that the adopters of the LIP clearly mark on their conformance statement the versions of the vocabularies that they support. Systems exchanging learner information using the LIP should ensure that their systems are using compatible vocabularies.

### 7.4.3 Data Entry Using the Vocabularies

An example of data entry using the vocabularies:

       <activity>

           <evaluation>

              <result>

                  <score>

                     <fieldlabel>

                         <typename>

                            <tyvalue>Score</tyvalue>

                         </typename>

                     </fieldlabel>

                     <fielddata>65</fielddata>

                  </score>

              </result>

           </evaluation>

       </activity>

In this example a result is defined in which the field label is ‘Score’ and the corresponding data entry for the score is ‘65’. Note that an associated vocabulary has not been defined as this could be considered unnecessary as just the label of the data field is required. If considered necessary then an appropriate vocabulary could be included; there are no corresponding default IMS vocabularies.

## 7.5 Building Relationships within the LIP

During the development of the LIP specification many of the core data structures had pointers to some of the other core data structures thereby showing a relationship. It became clear that we could not define all of the relationships between the core data structures and we did not wish to build a relational database within the LIP. Instead, the relationship core data structure was added. The relationship data structure supports the construction of arbitrary relations between the other core data structures within the LIP and also external data structures that can be identified using a sourcedid and/or indexid.

The underlying approach for defining a relationship is to identify, using a tuple, the source object, the destination object(s) and the relationship between them. Each tuple defines either a one-to-one or a one-to-many relationship. Many-to-many relationships require the creation of many tuples. Both the source and the destination are defined in terms of a sourcedid, indexid or sourcedid.indexid. The actual relationship, defined within the tuplerelation element, uses the standard LIP vocabulary mechanism. At the present time there is no default IMS vocabulary to support these definitions.

Once the relationship data structure had been considered it was realised it could be used in ways that had not been originally envisaged. The ways in which the relationship structure can be used are to create:

- A relationship between two or more data structures contained within an LIP (these data structure must have an associated sourcedid or indexid);

- A relationship between two or more learner profiles. Each learner profile has a sourcedid and so these can be related;

- The relationship between the internal data structure referencing mechanism and the exchange reference mechanism inherent within LIP. This is the equivalent of exchanging the mapping tables or dictionary between the communication profile servers;

- The relationship between two or more externally defined referencing mechanisms. This means that the relationship data structure can be used to exchange the relational database between any two systems.

This approach means that the relationships are defined by the communicating systems and not established as part of the specification itself. A consequence of this is that two identical transactions may define different relationships between the data itself.

## 7.6 Identifiers

The LIP is capable of supporting the exchange of data between distributed learner information systems. This is achieved by using a flexible referencing system that can be used to identify the learner information record and data structures within that record. The two separate referencing mechanisms are based upon the following identifiers:

- Sourcedid – the learner information record identifier. This consists of a source label, unique to the source responsible for creating the learner information, and the identifier of the record within that source. The source is responsible for ensuring that each different learner information record has a unique identifier. The uniqueness of the source label is outside of the scope of this specification and assumes that each learner information server has an unique source label pre-assigned to it. Once IMS has agreed the definition mechanism for the Global User Identifier (GUID) it is assumed that this will be the basis for the generation of the unique ‘sourcedid’;

- Indexid – the eleven core data structures and the associated sub-structures used to contain the learner information may be assigned an index number that is unique within the learner information record as a whole. This allows later operations on the record to identify the appropriate piece of information thereby requiring only that piece of information to be transferred as opposed to the full learner information. An important implication for this approach is that the indexid is a persistent pointer and so a system that uses it must maintain a mapping table between the indexid (as used for interoperability) and the local database address resolution structure.

A sourcedid takes the form of:

       <contentype>

           <referential>

              <sourcedid>

                  <source>IMS_LIP_V1p0_Example</source>

                  <id>1001</id>

              </sourcedid>

           </referential>

       </contentype>

An indexid takes the form of:

       <contentype>

           <referential>

              <indexid>interest_01</indexid>

           </referential>

       </contentype>

The key points to note about the two identifier mechanisms are:

- The LIP allows both the sourcedid and indexid technique to be used to identify any data structure. The only difference between the two identifiers is that the indexid is only required to be unique with respect to the full learner information profile for a learner i.e. for all LIP components for the full profile whereas the sourcedid should be globally unique;

- A profile may have more than one sourcedid. The mapping of the sourcedids to the same profile is beyond the scope of the specification but it is an important implementation consideration. It may be that no relationship between the multiple sourcedids is to be supplied – this may be because of security considerations etc;

- The persistence of the indexids is only required if some form of transaction processing between the communication systems is to be supported. Persistence is only required between the communicating systems as some internal mapping between the indexids and the local referencing system may be employed;

- The use of identifiers is not a requirement. If the order of the information in a LIP instance is predefined and persistent then another referencing system may not be required.

## 7.7 Packaging, Transactions, Messaging & Protocols

The LIP is concerned with defining the data model for the information that is to be exchanged by Profile servers. The realisation of the actual exchange of information requires many more system features. A schematic representation of the layered profiles system architecture is shown in Figure 7.1

Figure 7.1 A schematic model of layer-based communicating profile servers.

The exchange of learner information is based upon the following constructs:

- Learner information package – this is the data model for the exchange of the learner information and is defined within the IMS LIP specifications. This is the only layer defined within the IMS LIP specifications;

- Aggregated learner information packaging – the packaging of multiple LIPs can be used to collect together related information or a set of individual records that need to be exchanged between different organisations. The IMS Content Packaging specification is adopted for this exchange (see Section 6.1.2);

- Learner information transaction – the basic operation on the learner information e.g. create a learner information structure, change a learner information structure, delete a learner information structure, etc. This transaction requires the definition of the appropriate behavioural model which must be supported using a corresponding service and protocol;

- Learner information message – the actual messages/objects that are exchanged by the learner information entities. A protocol consists of the exchange of one or more learner information messages and this should be supported using an XML-based messaging mechanism. This XML-based messaging system is also applicable to the other IMS specifications;

- Generic messaging – the messaging and object management system that is used to encapsulate the XML messages/objects. This could be based upon SOAP, CORBA, etc;

- Communications system – the underlying communications architecture that is responsible for supplying a reliable end-to-end communications link. Typically, but not exclusively, this system will be based upon the Transmission Control Protocol/Internet Protocol combination (TCP/IP);

- Physical communications link – this is the actual data network that is used to interconnect the communicating profile servers. Typically these systems will be interconnected using a combination of wide-area and local-are networks (LAN/WAN).

Profiles servers that wish to exchange LIP information will have to agree on an equivalent architecture. At some time in the future IMS will make a series of recommendations concerning the implementation of the XML transaction, XML-based messaging and generic messaging layers. These recommendations will focus on simplifying successful interoperability.

## 7.8 Security Architectures & Considerations[1]

Definition of the security architecture within which the LIP records are exchanged is outside of the scope of the LIP specification. However, we briefly describe the ways in which different security issues and architectures can be supported using the LIP data structures:

- LIP identifiers;

- Access control;

- Privacy;

- Data integrity;

- Miscellaneous.

It is considered an essential part of the LIP architecture that the appropriate security features are supported. In Figure 7.1 this could mean that these security features are supported in several of the different layers to create a trusted communication system.

### 7.8.1 LIP Identifiers

The LIP identifiers are logical identifiers for the learner information as a whole and the LIP data structures as components. As such this information is for labelling. The sourcedid information is considered a globally unique identifier and as such it an essential piece of information to be used in identifying the learner information record. Access to and/or presentation of this identifier should not be considered the equivalent of allowing access to the corresponding information.

### 7.8.2 Access Control

Typically, learner information may be accessed by learners, their agents e.g. parents and other authorized representatives. Not all administrative personnel have access to learner information. There may be restrictions on the kind of learner information that can be stored and can be changed.

The learner information can be structured according to the learner’s environment. If the learner is alone and not collaborating, then the learner information might be minimal and, probably, private. If the learner is in a traditional learning institution where there are well-defined roles e.g. classmate, teacher, instructor, principal, etc. yet there is little on-line collaboration among learners, then the learner information might describe these institutional relationships, and the information might be private. If the learner is in an on-line, collaborative environment, then this kind of relationship information may be stored as learner information, and portions of the learner information might be available to other collaborators. Some parts of learner information is very private e.g. private keys, while other parts are made available to the public e.g. public keys. If role-based access control is used e.g. a teacher can change the grades of his/her students, then learner information might describe the relationship and would describe the associated security parameters.

The LIP allows an access control statement to be assigned to any of the core or component data structures – see Section 7.3.3 (these are not mandatory). How the communicating systems use this information is beyond the scope of the LIP specification but the appropriate handling of this information should be covered in the corresponding implementation policy.

### 7.8.3 Privacy

Privacy can be defined as ‘A technical policy about information security that reduces outbound security threats to an acceptable level’. Privacy may include: controlling the copying of information and/or controlling transfer of information. The policy may be implemented with various techniques, technologies, procedures, and/or practices. Various security techniques may implement privacy, such as: physical security, confidentiality, permitting retrieval or read access only to authorized entities, and/or prohibiting retrieval and read access to unauthorized entities. Various security technologies may implement privacy, such as: access control and encryption. Policy-makers, such as regulators, institutional administrators, and users, may mandate privacy but may choose different (yet compatible) implementations of privacy policy.

The LIP allows a privacy statement to be assigned to any of the core or component data structures – see Section 7.3.3 (these are not mandatory). How the communicating systems use this information is beyond the scope of the LIP specification but the appropriate handling of this information should be covered in the corresponding implementation policy.

### 7.8.4 Data Integrity

Data integrity can be defined as ‘A technical policy about information security that reduces inbound security threats to an acceptable level’. Data integrity may include: controlling the creation of information and/or controlling changes to information. The policy may be implemented with various techniques, technologies, procedures, and/or practices. Various security techniques may implement data integrity, such as: physical security, permitting storage or write access only to authorized entities, and/or prohibiting storage and write access to unauthorized entities. Various security technologies may implement data integrity, such as: digital signatures, access control, and read-only media. Policy makers, such as regulators, institutional administrators, and users, may mandate data integrity but may choose different, yet compatible, implementations of integrity policy.

Support for data integrity is outside the scope of the LIP. We would expect that the exchange of LIP instances is supported using an appropriate trusted communications system that guarantees data integrity. However, in the privacy statement to be assigned to any of the core or component data structures – see Section 7.3.3 – it s possible to include a checksum that can be used to detect unauthorised alteration of the data.

### 7.8.5 Miscellaneous

#### Nomadic Access

Learning technology components may need to read/write learner information in nomadic (sometimes-connected) environments. Many of these systems have local content e.g. CD-ROM, but remote or distance records management systems. Nomadic access is one way in which the LIP instances may be exchanged.

#### Granularity

Learner information is stored in various levels of granularity. It is desirable to exclude or include certain levels when retrieving records from the profile server. The LIP supports the exchange of any level of granularity of the learner information.

## 7.9 Distributed Architectures & Considerations

Definition of the distributed architecture within which the LIP records are exchanged is outside of the scope of the LIP specification. However, we briefly describe the ways in which different distributed architectures can be supported using the LIP data structures:

- LIP identifiers – the global uniqueness of the sourcedid means that in principle any learner information record can be identified using this identifier. It is possible for the learner information to have more than one sourcedid however the ways in which their relationship is reconciled is a system implementation issue (it may use the relationship structure in the LIP);

- Commitment, concurrency, recovery and replication – this is normally considered a feature of the transaction and the messaging components of a system. These functions are outside the scope of the LIP specification;

- Transaction granularity and scalability – the LIP has been designed so that as much or as little information needs to be exchanged. This means that the LIP is ideal for sending both small and large amounts of information in either a single or a group of packaged LIP instances;

- Nomadic access – nothing in the operation of the LIP excludes support for nomadic-access systems. Indeed, the variation in granularity levels, the usage of a flexible indexing system and support for temporal and privacy meta-data makes the LIP ideal for learner information exchange between nomadic-access systems.

# 8. V2.0 Elements

The elements listed in Table 8.1 are used to indicate where new functionality will be added in later releases of the specifications:

Table 8.1 List of V1.x/2.0 specific elements.

Extension Element Name | Host Element | Description
disability | accessibility | Used to contain information concerning the learner’s range of disabilities and learning difficulties. Will incorporate the work undertaken by the IMS Accessibility working-group.
eligibility | accessibility | Used to contain information concerning the issues of the learner’s eligibility e.g. for sponsorship, prerequistities, etc.
competency | competency | Will incorporate the work undertaken by the IMS Competency Definitions working-group.
transcript | transcript | Will incorporate the work that is currently being undertaken by the ANSI X.12 group.
taxonomy | learnerinformation | Will be used to incorporate the definition of taxonomies that will be used to support the core data objects.

Note:

The structure of these elements will change in V1.x/V2.0 releases of these specifications. Their main role is to indicate the type of functions to be included in later releases of these specifications and as such vendors are encouraged NOT to make use of these in V1.0 implementations.

# 9. Extensibility

The proprietary extensions facilities listed in Table 9.1 are supported as elements within the specifications:

Table 9.1 List of proprietary extension elements.

Extension Element Name | Host Element | Description
ext_accessibility | accessibility | Allows the inclusion of proprietary features to the accessibility core data structure. A single extension is permitted per instance.
ext_activity | activity | Allows the inclusion of proprietary features to the activity core data structure. A single extension is permitted per instance.
ext_affiliation | affiliation | Allows the inclusion of proprietary features to the affiliation core data structure. A single extension is permitted per instance.
ext_competency | competency | Allows the inclusion of proprietary features to the competency core data structure. A single extension is permitted per instance.
ext_contentype | contentype | Allows the inclusion of proprietary features to the contentype element that is a part of all the core data structures, the root element and many other data objects.
ext_date | date | Allows the inclusion of proprietary features to the date element that is a part of the several core data structures.
ext_definition | definition | Allows the inclusion of proprietary features to the definition element that is a part of the activity core data structure.
ext_disability | disability | Allows the inclusion of proprietary features to the disability element that is a part of the accessibility core data structure. Note that the eligibility element is for development in further releases of the specification.
ext_eligibility | eligibility | Allows the inclusion of proprietary features to the eligibility element that is a part of the accessibility core data structure. Note that the eligibility element is for development in further releases of the specification.
ext_evaluation | evaluation | Allows the inclusion of proprietary features to the evaluation element that is a part of the activity core data structure.
ext_exrefrecord | exrefrecord | Allows the inclusion of proprietary features to the exrefrecord element that is a part of the several core data structures.
ext_goal | goal | Allows the inclusion of proprietary features to the goal core data structure. A single extension is permitted per instance.
ext_identification | identification | Allows the inclusion of proprietary features to the identification core data structure. A single extension is permitted per instance.
ext_interest | interest | Allows the inclusion of proprietary features to the interest core data structure. A single extension is permitted per instance.
ext_language | language | Allows the inclusion of proprietary features to the language element that is a part of the accessibility core data structure.
ext_learnerinfo | learnerinformation | Allows the extension of the root element structure. This enables new core data structures to be added to the root. Note that new core structures could be considered for adoption within the main framework in later releases of the specification.
ext_objectives | objectives | Allows the inclusion of proprietary features to the objectives element that is a part of the evaluation element within the activity core data structure.
ext_preference | preference | Allows the inclusion of proprietary features to the preference element that is a part of the accessibility core data structure.
ext_product | product | Allows the inclusion of proprietary features to the product element that is a part of several core data structures.
ext_qcl | qcl | Allows the inclusion of proprietary features to the qcl core data structure. A single extension is permitted per instance.
ext_relationship | relationship | Allows the inclusion of proprietary features to the relationship core data structure. A single extension is permitted per instance.
ext_role | role | Allows the inclusion of proprietary features to the role element that is a part of the affiliation core data structure.
ext_securitykey | securitykey | Allows the inclusion of proprietary features to the securitykey core data structure. A single extension is permitted per instance.
ext_testimonial | testimonial | Allows the inclusion of proprietary features to the testimonial element that is a part of the activity core data structure.
ext_transcript | transcript | Allows the inclusion of proprietary features to the transcript core data structure. A single extension is permitted per instance.

Note:

The working-group considers these extensions as a key capability within the LIP specification and unlike some of the other specifications makes a guarantee to provide these extension points in all further releases of the specification. This is because we recognise that the LIP will never be definitive (indeed we have not and will not be attempting to make it definitive) in terms of including all possible types of learner information and that extensions used in specific systems is desireable.

[1] Many of the issues raised in this sub-Section are derived from similar ones raised within the IEEE PAPI v6 draft specification. The key difference is that we have shown how these issues can be supported using the features of the LIP.

# 10. Conformance

The purpose of this conformance statement is to provide a mechanism for customers to fairly compare vendors of Learner Information content and tools. It is not required for a vendor to support every feature to claim conformance, however, a vendor must detail their level of conformance with a “Conformance Statement”. As such this is an Informative Conformance statement only.

## 10.1 Valid Data Issues

Vendors claiming conformance shall be able to read and write valid instances of the learner information data as defined by the XML Schema including proprietary extensions where applicable. For the handling of an IMS LIP instance the conformance statement shall:

- Indicate that all of the mandatory information model elements are correctly formed and located within the instance;

- Indicate that all of the optional information model elements are correctly formed and located when relevant to the instance;

- Indicate where the extension facilities made available within the LIP have been used and/or required.

## 10.2 Conformance Statement

Vendors claiming conformance must provide a “Conformance Statement”, detailing their level of conformance. The Conformance Statement takes the form of twelve tables, namely:

- Table 10.1 – <learnerinformation> data structure conformance;

- Table 10.2 – <accessibility> data structure conformance;

- Table 10.3 – <activity> data structure conformance;

- Table 10.4 – <affiliation> data structure conformance;

- Table 10.5 – <competency> data structure conformance;

- Table 10.6 – <goal> data structure conformance;

- Table 10.7 – <identification> data structure conformance;

- Table 10.8 – <interest> data structure conformance;

- Table 10.9 – <qcl> data structure conformance;

- Table 10.10 – <relationship> data structure conformance;

- Table 10.11 – <securitykey> data structure conformance;

- Table 10.12 – <transcript> data structure conformance.

In each table the relevant tick-boxes are checked to indicate that the corresponding property is supported. The conformance statement then becomes the collection of the checked tick-boxes.

### 10.2.1 Learnerinformation Conformance Statement Table

Table 10.1 Learnerinformation conformance statement table.

Learnerinformation |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment identification accessibility goal | qcl activity competency interest | affiliation transcript securitykey relationship
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_learnerinfo

### 10.2.2 Accessibility Conformance Statement Table

Table 10.2 Accessibility conformance statement table.

Accessibility |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment | language | preference
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_accessibility ext_language ext_preference ext_disability ext_eligibility

### 10.2.3 Activity Conformance Statement Table

Table 10.3 Activity conformance statement table.

Activity |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment date status units | learningrefactivity product definition evaluation | testimonial status description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_activity ext_definition ext_product ext_testimonial ext_evaluation

### 10.2.4 Affiliation Conformance Statement Table

Table 10.4 Affiliation conformance statement table.

Affiliation |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment affiliationid role | organization date | status description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_affiliation ext_role

### 10.2.5 Competency Conformance Statement Table

Table 10.5 Competency conformance statement table.

Competency | #
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment | exrefrecord | description
Extension Fields: These features allow the data model to be extended.
Functions
ext_competency ext_exrefrecord

### 10.2.6 Goal Conformance Statement Table

Table 10.6 Goal conformance statement table.

Goal |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment date | priority status | description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_goal

### 10.2.7 Identification Conformance Statement Table

Table 10.7 Identification conformance statement table.

Identification |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment formname name contactinfo telephone facsimile mobile pager email web | address pobox street locality city country statepr region postcode timezone geo | demographics representation gender date uid agent agentid agentdomain description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_identification

### 10.2.8 Interest Conformance Statement Table

Table 10.8 Interest conformance statement table.

Interest |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment | product | description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_interest ext_product

### 10.2.9 Qcl Conformance Statement Table

Table 10.9 Qcl conformance statement table.

Qcl |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment title organization | registrationno level | date description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_qcl

### 10.2.10 Relationship Conformance Statement Table

Table 10.10 Relationship conformance statement table.

Relationship |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment tuplesource | tuplerelation tupledest | description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_relationship

### 10.2.11 Securitykey Conformance Statement Table

Table 10.11 Securitykey conformance statement table.

Goal |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment | keyfields | description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_securitykey

### 10.2.12 Transcript Conformance Statement Table

Table 10.12 Transcript conformance statement table.

Transcript |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment | exrefrecord | description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_transcript ext_exrefrecord

## 10.3 A Conformance Statement Example

In the following tables is an example of how the conformance Tables 10.1 to 10.12 can be completed. In this example only the <identification> and <qcl> core data structures are supported. This gives rise to the three conformance tables of:

- Table 10.13 – the example learnerinformation conformance statement.

- Table 10.14 – the example identification conformance statement.

- Table 10.15 – the example qcl conformance statement.

Table 10.13 Example learnerinformation conformance statement table.

Learnerinformation |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment identification accessibility goal | qcl activity competency interest | affiliation transcript securitykey relationship
Extension Fields: These features allow the data model to be extended.
Vocabularies 3typename | Functions ext_learnerinfo

Table 10.14 Example identification conformance statement table.

Identification |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment formname name contactinfo telephone facsimile mobile pager email web | address pobox street locality city country statepr region postcode timezone geo | demographics representation gender date uid agent agentid agentdomain description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_identification

Table 10.15 Example qcl conformance statement table.

Qcl |
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
contentype
referential | temporal | privacy
comment title organization | registrationno level | date description
Extension Fields: These features allow the data model to be extended.
Vocabularies typename | Functions ext_qcl

The salient features to note from Tables 10.13, 10.14 and 10.15 are:

- The entries in Table 10.13 show that only the <identification> and <qcl> core data structures are supported. No extensions are supported at the <learnerinformation> level. All of the mandatory features are supported. All of the vocabularies are supported and their associated extension facilities;

- The entries in Table 10.14 show that all of the mandatory features are supported. All of the <comment>, <formname>, <name>, <contactinfo>, <demographics> and <description> features are supported. Within the <address> element the <region>, <timezone> and <geo> features are not supported (thus the <address> tick-box is unmarked). Within the extension features no functional extensions are permitted i.e. <ext_identification> is not supported;

- The entries in table 10.15 show that all of the features are supported within the <qcl> with the exception of the extension function i.e. the element <ext_qcl> is not supported.

# Appendix A – LIP and its Schemas

## A1 Overview

The Version 1.0 IMS Learner Information Packaging XML Schema (XSD) and Document Type Definitions (DTDs) files are contained in a directory that has:

- xmla - the directory that contains all of the XSDs and DTDs in native XML Authority format. XML Authority (v1.2) is a product supplied by eXtensibility Inc;

- mac - the directory that contains all of the XSDs and DTDs in text file format. These text files are designed for usage with Macintosh systems;

- ibm- the directory that contains all of the XSDs and DTDs in text file format. These text files are designed for usage with PC systems;

- unix- the directory that contains all of the XSDs and DTDs in text file format. These text files are designed for usage with Unix systems.

The further directory structure under each of these directories is identical. This further structure is:

- XSDs

  – LIPfulldtd - full commented XSD

  – LIPfullncdtd - full non-commented XSD;

- DTDs

  – LIPfulldtd - full commented DTD

  – LIPfullncdtd - full non-commented DTD;

  Within each of the directories the schema file name is:

- XSD directory: ims_lip_rootv1p0.xsd;

- DTD directory: ims_lipv1p0.dtd;

This approach means that the different types of XSD and DTD can be applied without requiring any editing of the associated source XML files. The full directory structure is given in Appendix A4 of this document.

## A2 Features of the Different DTDs/XDRs

The key features of the different DTD/XDR implementations are:

- LIPfull/xsd/dtd – this is the full XSD/DTD with all of the corresponding comments. The comments are used to provide an explanation of the intended functionality of the corresponding schema component;

- LIPfullnc/xsd/dtd – this is the full XSD/DTD but with all of the comments removed. This makes the file smaller and it is easier to see the internal structure.

## A3 Recommended Usage of the XSDs and DTDs

The recommended uses of the different XSDs/DTDs are:

- Select the set of XSDs/DTDs that suit your system. All of the mac/unix/ibm text versions are derived from the XML Authority version and created using the Alpha text processing application;

- In most cases only the non-commented versions need to be used. The fully commented files are intended to be informative;

- The DTD set is based upon a monolithic binding whereas the XSD uses a set of included files. It is recommeneded that the XSD is used whenever possible as the DTD is supplied on an informative basis whereas the XSD is treated as the normative version of the specification.

## A4 Full Directory Structure

The full directory structure is:

Xmla xsds LIPfullxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd LIPfullncxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd dtds LIPfulldtd ims_lipv1p0.dtd LIPfullncdtd ims_lipv1p0.dtd | Mac xsds LIPfullxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd LIPfullncxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd dtds LIPfulldtd ims_lipv1p0.dtd LIPfullncdtd ims_lipv1p0.dtd
Unix xsds LIPfullxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd LIPfullncxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd dtds LIPfulldtd ims_lipv1p0.dtd LIPfullncdtd ims_lipv1p0.dtd | IBM xsds LIPfullxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd LIPfullncxsd ims_lip_rootv1p0.xsd ims_lip_accessibilityv1p0.xsd ims_lip_activityv1p0.xsd ims_lip_affiliationv1p0.xsd ims_lip_competencyv1p0.xsd ims_lip_goalv1p0.xsd ims_lip_identificationv1p0.xsd ims_lip_interestv1p0.xsd ims_lip_qclv1p0.xsd ims_lip_relationshipv1p0.xsd ims_lip_securitykeyv1p0.xsd ims_lip_transcriptv1p0.xsd ims_lip_attributesv1p0.xsd ims_lip_commonlipv1p0.xsd ims_lip_descriptionv1p0.xsd ims_lip_evaluationv1p0.xsd ims_lip_exrefrecordv1p0.xsd ims_lip_extensionv1p0.xsd ims_lip_mediav1p0.xsd ims_lip_organizationv1p0.xsd ims_lip_rolev1p0.xsd ims_lip_tuplev1p0.xsd dtds LIPfulldtd ims_lipv1p0.dtd LIPfullncdtd ims_lipv1p0.dtd

# Appendix B - The LIP XML Instance Example Files

The full set of example files, as referred to in Sections 4 and 5 are available as part of the Learner Information Package Resource Kit. Each XML example directory contains the files necessary to support the LIP example. The XML files are denote by an ‘.xml’ extension. The following tables list the name of each example directory, the nature of the example in terms of data structures. The tables are:

- Table B1 - valid basic examples with the parent directory name of ‘IMS_LIPv1p0/Valid/Basic’;

- Table B2 - valid advanced examples with the parent directory name of ‘IMS_LIPv1p0/Valid/Advanced’.

Table B1 The LIP XML instance valid basic example files.

Directory Name | Data Object | Description
accs_001 | accessibility | The creation of an accessibility record using a new sourcedid.
accs_lang_001 | accessibility.language | The creation of a language proficiency record using a new sourcedid.
accs_lang_002 | accessibility.language | A second language proficiency definition using the sourcedid created in the ‘accs_lang_001’ example.
accs_pref_001 | accessibility.preference | The creation of a preference record using a new sourcedid.
accs_pref_002 | accessibility.preference | A second preference using the sourcedid created in the ‘accs_pref_001’ example.
actv_001 | activity | The creation of an activity record using a new sourcedid.
actv_defn_001 | activity_definition | The creation of an activity definition record using a new sourcedid.
actv_defn_002 | activity_definition | The creation of a second activity definition record using a the sourcedid from ‘actv_defn_001’.
actv_eval_001 | activity_evaluation | The creation of an activity evaluation record using a new sourcedid.
actv_eval_002 | activity_evaluation | The creation of a second activity evaluation record using a the sourcedid from ‘actv_eval_001’.
actv_lref_001 | activity_learningactivityref | The creation of an activity learner activity reference record using a new sourcedid.
actv_lref_002 | activity_learningactivityref | The creation of a second activity learner activity reference record using a the sourcedid from ‘actv_defn_001’.
actv_prod_001 | activity_product | The creation of an activity product record using a new sourcedid.
actv_prod_002 | activity_product | The creation of a second activity product record using a the sourcedid from ‘actv_prod_001’.
actv_test_001 | activity_testimonial | The creation of an activity testimonial record using a new sourcedid.
actv_test_002 | activity_testimonial | The creation of a second activity testimonial record using a the sourcedid from ‘actv_test_001’.
affl_001 | affiliation | The creation of a new affiliation record using for a new learner sourcedid.
affl_002 | affiliation | The creation of a new affiliation record using for a new learner sourcedid.
affl_003 | affiliation | The creation of a second affiliation record using for the learner sourcedid used in ‘comp_002’.
comp_001 | competency | The creation of a new competency record using for a new learner sourcedid.
comp_002 | competency | The creation of a new competency record using for a new learner sourcedid.
comp_003 | competency | The creation of a second competency record using for the learner sourcedid used in ‘comp_002’.
goal_001 | goal | The creation of a new goal record using for a new learner sourcedid.
goal_002 | goal | The creation of a new goal record using for a new learner sourcedid.
goal_003 | goal | The addition of a sub-goal to the previously created goal record in example ‘goal_002’.
iden_001 | identification | The creation of an identification record using a new sourcedid.
iden_addr_001 | identification_address | The creation of an address record using a new sourcedid.
iden_addr_002 | identification_address | A second address record using the sourcedid created in the ‘iden_addr_001’ example.
iden_agnt_001 | identification_agent | The creation of an agent record using a new sourcedid.
iden_agnt_002 | identification_agent | A second agent record using the sourcedid created in the ‘iden_agnt_001’ example.
iden_cinf_001 | identification_contactinfo | The creation of a contact information record using a new sourcedid.
iden_cinf_001 | identification_contactinfo | A second contacvt information using the sourcedid created in the ‘iden_cinf_001’ example.
iden_demo_001 | identification_demographics | The creation of a demographics record using a new sourcedid.
iden_demo_002 | identification_demographics | A second demographics record using the sourcedid created in the ‘iden_demo_001’ example.
iden_fnme_001 | identification_formname | The creation of a formatted name record using a new sourcedid.
iden_fnme_002 | identification_formname | A second formatted name record using the sourcedid created in the ‘iden_fnme_001’ example.
iden_name_001 | identification_name | The creation of a compound name record using a new sourcedid.
iden_name_002 | identification_name | Changing of the previously created name record using the reference information given in example ‘iden_name_002’.
intt_001 | interest | The creation of a new interest record using for a new learner sourcedid.
intt_002 | interest | The creation of a new interest record using for a new learner sourcedid.
intt_003 | interest | The creation of a second interest record using for the learner sourcedid used in ‘comp_002’.
qcln_001 | qcl | The creation of a new qcl record using for a new learner sourcedid.
qcln_002 | qcl | The creation of a new qcl record using for a new learner sourcedid.
qcln_003 | qcl | The creation of a second qcl record using for the learner sourcedid used in ‘comp_002’.
rltp_001 | relationship | The creation of a new relationship record using for a new learner sourcedid.
rltp_002 | relationship | The creation of a new relationship record using for a new learner sourcedid.
rltp_003 | relationship | The creation of a second relationship record using for the learner sourcedid used in ‘comp_002’.
skey_001 | securitykey | The creation of a new securitykey record using for a new learner sourcedid.
skey_002 | securitykey | The creation of a new securitykey record using for a new learner sourcedid.
skey_003 | securitykey | The creation of a second securitykey record using for the learner sourcedid used in ‘comp_002’.
trns_001 | transcript | The creation of a new transcript record using for a new learner sourcedid.
trns_002 | transcript | The creation of a new transcript record using for a new learner sourcedid.
trns_003 | transcript | The creation of a second transcript record using for the learner sourcedid used in ‘comp_002’.

Table B2 The LIP XML instance valid advanced example files.

Directory Name | Data Object | Description
engresume | Mixed | Engineering resume.
isrmapv1 | Mixed | UK FEFC Individualised Student Record (ISR) to IMS LIP mapping version 1 – optimised to minimise instance size.
isrmapv2 | Mixed | UK FEFC Individualised Student Record (ISR) to IMS LIP mapping version 2 – optimised for data sequencing.

# Appendix C – Glossary of Terms

## C1 General Terms

ADL | The Advanced Distributed Learning initiative was started in 1997 by the United States White House. Its aim is to advance the use of online training.
AICC | Aviation Industry CBT Committee is a membership-based international forum that develops recommendations on interoperable learning technologies.
Conformance statement | A conformance statement provides a mechanism for customers to fairly compare vendors of assessment tools and content.
DTD | Document Type Definition.
Element | An XML term that defines a component within an XML document that has been identified in a way a computer can understand.
Element attributes | Provides additional information about an element.
Element contents | An XML term used to describe the content of the element.
HR-XML | The HR-XML is a group of companies attempting to define XML representations to support Human Resource activities. At present they have developed three DTDs for activities such as resume exchange, etc. The relationship between the IMS LIP and the HR-XML DTDs is discussed in this document.
IEEE | Institute of Electrical and Electronics Engineers that provides a forum for developing specifications and standards.
IMS | An organization dedicated to developing specification for distributed learning.
IMS Enterprise | The IMS Enterprise specification complements the IMS LIP. The Enterprise specification should be used for the exchange of group and membership information e.g. members of a particular class, cohort, etc.
IMS Meta-data | The IMS meta-data specification was released in October 1999. This was the first specification released by IMS. It is compatible with the IEEE LOM and Dublin Core.
IMS QTI | The IMS Question & Test Interoperability specification was issued by IMS in May 2000 with version 1.1 being released in March 2001. This specification is under consideration for adoption by several of the other specification and standards development organisations.
LMS | Learning Management System that is the system responsible for the management of the learning experience.
LTSC | The IEEE’s Learning Technology Standards Committee
Metadata | Tags that described the content of the associated data.
PAPI | The IEEE Personal & Private Information specification is being developed by the IEEE LTSC. The relationship between the IMS LIP and the IEEE PAPI is discussed in this document.
SIF | The Schools Interoperability Framework is an activity focussed on the development of specifications for the exchange of information between the K-12 schools. The relationship between the IMS LIP and the SIF is discussed in this document.
vCard | vCard is an IETF proposal for an electronic business card representation. It has not yet been adopted as an RFC. A vCard DTD has been developed and its core features have been adopted by the IMS LIP. The relationship between the IMS LIP and vCard is discussed in this document.
W3C | World Wide Web Consortium.
XDR | The XML Data Representation format is a Microsoft XML schema. XDR schema is more powerful representation than DTDs.
XML | Extensible Mark-up Language is a specification, produced by the World Wide Web Consortium.
XSD | XML Schema is the preferred IMS binding for XML.

## C2 LIP Elements and Attributes

accessibility | The accessibility learner information is one of the eleven core data structures. It is the learner information that consists of the cognitive, technical and physical preferences for the learner, their language capabilities, disability and eligibilities. Multiple accessibility definitions are permitted for each learner.
activity | The activity learner information is one of the eleven core data structures. It consists of the education/training, work and service (military, community, voluntary, etc.) record and products (excluding formal awards). This information may include the descriptions of the courses undertaken and the records of the corresponding evaluation. Each activity has its own structure and an activity may contain sub-activities.
address | The address element is a part of the identification element. The address contains information such as the street (this is a complex structure in its own right), state, country, zip code, geographic location, etc. Each address has an associated type (defined using typename) and different addresses must be contained in multiple instances of the address element.
affiliation | The affiliation learner information is one of the eleven core data structures. It is used to store the descriptions of the affiliations associated with the learner e.g. professional affiliations. A learner’s membership of the relevant class, cohorts, groups, etc. undertaken when being educated, trained, etc. should be supported using the IMS Enterprise specification. Each affiliation is contained within its own instance.
affiliationid | The affiliationid element is used within the affiliation element. It is used to contain the reference number assigned by the institution to which the leaner is claiming an affiliation i.e. their membership number. The data is entered as a string of up to 128 characters.
agent | The agent element is used within the identification element. It is used to store the details concerning representatives who can act on behalf of the learner. The types of agent are Parent, Guardian, Advisor, etc. (these are defined as part of the typename element). The details for each agent are contained within its own agent element.
agentdomain | The agentdomain element is used within the agent element. It is used to define the role that the agent is permitted to undertake on behalf of the learner. The types of role permitted are legal, sponsor, etc. (these are defined as part of the typename element).
agentid | The agentid element is used within the agent element. It is used to contain the identifier assigned to the agent e.g. their name, reference number, etc.
aptnumber | The aptnumber element is used within the street element that itself forms a part of the address element. This element is used to contain the apartment number component of the learner’s address. Prefix and suffix components of the apartment number are available as other elements.
aptnumprefix | The aptnumsuffix element is used within the street element that itself forms a part of the address element. This element is used to contain the prefix component of the apartment number. This element should be used in conjunction with the aptnumber element.
aptnumsuffix | The aptnumsuffix element is used within the street element that itself forms a part of the address element. This element is used to contain the suffix component of the apartment number e.g. the ‘A’ for an apartment number of 34A. This element should be used in conjunction with the aptnumber element.
apttype | The apttype element is used within the street element that itself forms a part of the address element. It is used to contain the type of apartment component of the address. The attribute xml:lang is used to define the language of the string entry.
areacode | The areacode element is used within the telephone, facsimile, pager and mobile elements. These elements are used to store the corresponding public switched telephone network number. In every case the associated number must include the areacode element.
city | The city element is used within the address element. This element is used to store the city name part of the learner’s address. The city name is entered as a string e.g. Boston, Sheffield, Sydney, Tokyo, etc. The attribute xml:lang is used to define the language.
classification | The classification element is used within the affiliation element. It is used define the nature of the affiliation within the organisation. The data is entered as a string.
comment | This is the commenting facility within the XML schemas. The comments can take any form supported as #PCDATA. The key difference between this comment style and the standard ‘<!-- *** -->’ is that the former is passed through the XML parser to the host system.
competency | The competency learner information is one of the eleven core data structures. It consists of the descriptions of the skills the learner has acquired. These skills may be associated with some formal or informal training or work history (described in the ‘activity’) and formal awards (described in the ‘qcl’). The corresponding level of competency may also be defined. Each competency is defined by its own structure. This data object will be reworked once the IMS Competency Definition working-group has completed its final specification.
complex | The complex element is used within the street element which is itself contained within the address element. It is used to contain the name of the building complex part of the street address. The xml:lang attribute is used to define the language of the entered information which is submitted as a string of up to 128 characters length.
contactinfo | The contactinfo element is used within the identification element. It is used to store the information describing the ways in which the learner can be contacted electronically. This includes telephone, pager, facsimile, mobile, email and web elements to contain the corresponding contact details e.g. the actual email address. Each piece of contact information must be stored within its own contactinfo element and the type of information is defined using the typename element – this is used to define whether the details refer to the home, work, etc.
contentref | The contentef element is used within the objectives element. It is used to enable the support of an external reference mechanism, as used to reflect the <matref> mechanism within the IMS QTI specification. The information will be entered as a string of up to 256 characters in length.
contentreftype | The contentreftype attribute is is used by the media element only. It is used to describe the nature of the manner in which the content material is stored. It consists of an enumerated list: ‘uri’, ‘entityref’ and Base-64 (Base-64 is the default value). The ‘uri’ value means that the material is stored in the file defined by the external reference. The ‘entityref’ value means that the file is linked using the XML ENTITY structure. The Base-64 value means that the material is embedded within the XML instance itself.
contentype | The contentype element is the container for the control information that is used to describe the learner information. This information consists of referential, temporal and privacy information and is applied to each of the ‘atomic data objects’ of the learner information structure. This structure consists of referential, temporal and privacy information.
country | The country element is used within the address element. It is used to store the country component of the address e.g. Brazil, China, etc. The xml:lang attribute is used to define the language of the entered information and it is submitted as a string of up to 256 characters in length.
countrycode | The countrycode element is used within the telephone, facsimile, pager and mobile elements. It is used to store the country code of the corresponding telephony number. The data is entered as a two integer in the range 00-99.
date | The date element is used by a variety of the other elements. It is used to contain any date related information such as the start date, publishing date, finish date, etc. The tupe of date is defined using the typename element.
datetime | The datetime element is used by the date element. It is used to contain the actual date and/or time information. The structure of the datetime should conform to the IS8601 standard and takes te form of: YYYY:MM:DDTHH:MM:SS i.e. year, month, day, hour, minute and second.
definition | The definition element is used with the activity element only. It is used to store the description of the structure of the activity being undertaken. The activity is represented using a polyhierarchical structure and so any level of granularity can be stored. The type of structure being defined is identified using the typename element.
definitionfield | The definitionfield element is used within the definition element only. It is used to contain the actual description of the activity structure using one or more occurences of the element. The structure is described using the fieldlabel and fielddata elements.
demographics | The demographics element is used within the identification element. It is used to store the learner information for demographic information about the learner e.g. gender, place of birth, etc. A single demographics element can be used to contain several pieces of related demographics information.
description | The description element is used by a variety of other elements. It is used to contain the materials for the data object. The description element can include one or more of the short, long and full elements. The intention is for these three elements to contain related information about the same object i.e. to supply progressively increasing details.
disability | The disability element is used within the accessibility element. This will be used to contain all of the information relevant to the disabilities and learning difficulties of the learner. This element is to be developed in further releases of this specification and in response to the work undertaken by the IMS Accessibility working-group.
duration | The duration element is used within the evaluation element which is itself used by the activity element. It is used to contain the information of the periods/durations associated with a particular evaluation e.g. the time taken to complete the examination. The nature of the duration is defined using the fieldlabel and fielddata elements.
eligibility | The eligibility element is used within the accessibility element. This will be used to contain all of the information relevant to the disabilities and learning difficulties of the learner. This element is to be developed in further releases of this specification and in response to the work undertaken by the IMS Accessibility working-group.
email | The email element is a part of the contactinfo element. It is used to store the email address of the learner. Multiple email addresses require the usage of multiple contactinfo instances. The information is supplied as string and should take the form of: ‘userid@host’.
entityref | The entityref attribute is used as an alternative to the uri attribute. The key difference is that the entityref refers to an XML entity whose external linkage is bound to the XML instance itself. This binding also allows the XML-capable processes to intelligently handle the material. It is recommended that this attribute be used in preference to the uri attribute.
evalmetadata | The evalmetadata element is used within the evaluation element only. This is used to store the evaluation specific meta-data. This element is particularly important when the IMS QTI Assessment, Section and Item and their meta-data content have to be stored.
evalmetadatafield | The evalmetadatafield is used within the evalmetadata element contain each of the individualised meta-data entries. Each field should be labelled accoding to the vocabulary defined within the evalmetadata element.
evaluation | The evaluation element is used within the activity element. It is used to store the information concerning the assessment/evaluation of the associated activity. The evaluation element is a recursive structure and so complex results information can be contained. This element is to be used to store all of the summary results interoperability information and as such it will be subject to harmonisation with the V1.2 and later releases of the IMS QTI specifications.
evaluationid | The evaluationid element is used within the evaluation element only. It is used to store the identifier that is used to identify the actual evaluation. This element is particularly useful when storing the IMS QTI Assessments, Section and Items as their ‘ident’ value can be stored.
exrefrecord | The exrefrecord element is used within the competency and transcript elements. It is used to store the arbitrarily formatted material used for the competency or transcript materials. The content format is defined using the recformat element and the actual material is stored using the recdata element.
ext_accessibility | The ext_accessibility element is used to support any of the proprietary functions that are required within the accessibility element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_activity | The ext_activity element is used to support any of the proprietary functions that are required within the activity element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_affiliation | The ext_affiliation element is used to support any of the proprietary functions that are required within the affiliation element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_competency | The ext_competency element is used to support any of the proprietary functions that are required within the competency element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_contentype | The ext_contentype element is used to support any of the proprietary functions that are required within the contentype element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_date | The ext_date element is used to support any of the proprietary functions that are required within the date element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_definition | The ext_definition element is used to support any of the proprietary functions that are required within the definition element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_disability | The ext_disability element is used to support any of the proprietary functions that are required within the disability element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_eligibility | The ext_eligibility element is used to support any of the proprietary functions that are required within the eligibility element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_evaluation | The ext_evaluation element is used to support any of the proprietary functions that are required within the evaluation element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_exrefrecord | The ext_exrefrecord element is used to support any of the proprietary functions that are required within the exrefrecord element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_goal | The ext_goal element is used to support any of the proprietary functions that are required within the goal element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_identification | The ext_identification element is used to support any of the proprietary functions that are required within the identification element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_interest | The ext_interest element is used to support any of the proprietary functions that are required within the interest element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_language | The ext_language element is used to support any of the proprietary functions that are required within the language element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_learnerinfo | The ext_learnerinfo element is used to support any of the proprietary functions that are required within the learnerinfo element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_objectives | The ext_objectives element is used to support any of the proprietary functions that are required within the objectives element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_preference | The ext_preference element is used to support any of the proprietary functions that are required within the preference element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_product | The ext_product element is used to support any of the proprietary functions that are required within the product element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_qcl | The ext_qcl element is used to support any of the proprietary functions that are required within the qcl element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_relationship | The ext_relationship element is used to support any of the proprietary functions that are required within the relationship element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_role | The ext_role element is used to support any of the proprietary functions that are required within the role element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_securitykey | The ext_securitykey element is used to support any of the proprietary functions that are required within the securitykey element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_testimonial | The ext_testimonial element is used to support any of the proprietary functions that are required within the testimonial element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
ext_transcript | The ext_transcript element is used to support any of the proprietary functions that are required within the transcript element. These functions will not be available in any of data objects currently defined. Backwards compatibility of the extension features is fully guaranteed.
extnumber | The extnumber element is used within the telephone and facsimile elements. It is used to store the extension number component of the telephony number. This information is entered as a string.
facsimile | The facsimile element is used within the contactinfo element. This element is used to store the appropriate fax machine number cf. the telephone element. The fax number can include the county code and extension number as well as the normal area code and actual number.
fielddata | The fielddata element is used by several other elements but it is always accompanied by the fieldlabel element. It is sued to store the actual information in the filed whose name is defined using the fieldlabel element. The data format is undefined i.e. #PCDATA.
fieldlabel | The fieldlabel element is used by several other elements but it is always accompanied by the fielddata element. It is used to contain the definition of the nature of the information to be stored in the fielddata element i.e. it is used to define the name of the field. The field name is defined using the typename element.
formname | The formname element is used within the identification element. It is used to store the formatted name of the learner. Each formatted name is exchanged using its own formname element. The data is stored within the text element. A formatted name can have any structure and each entry is supplied as a single string. The type of formatted name is defined using the stdname element e.g. ‘Contact’, ‘Full’, etc.
full | The full element is used within the description element. This element is used to contain any type of content material. The actual material is stored using the media element.
gender | The gender element is used within the demographics element to store the gender of the learner. It is an empty element and the information is entered through an attribute.
gender | The gender attribute is used by the gender element. The gender attribute consists of an enumerated list consisting of [M]ale, [F]emale and [N/A]. This attribute is a mandatory part of the gender element.
geo | The geo element is used within the address element which is itself within the identification element. It is used to contain the geographical location of the user is terms of latitude (the lat element) and longitude (the lon element).
goal | The goal learner information is one of the eleven core data structures. It consists of the description of the personal objectives and aspirations. These descriptions may also include information for monitoring the progress in achieving those goals. A goal can be defined in terms of sub-goals and each goal is defined within its own data structure.
id | The id element is used within the sourcedid element. It is used to store the unique identifier of the actual instance of the data instance being supplied. This identifier should be unique with respect to the associated source information however the way this is achieved and policed is beyond the scope of this specification.
identification | The identification learner information is one of the eleven core data structures. It contains all of the data for a specific individual or organisation. This includes data such as: names, addresses, contact information, demographic and representative agent.
indexid | The indexid element is used within the referential element which is within the contentype element. It is used to contain the unique identifier assigned to the data structure. This identifier must be unique with respect to the sourcedid element assigned to the learnerinformation element itself. The indexid identifier should be persistent for the same piece of information in whatever learnerinformation XML instance it is used.
indnumber | The indnumber element is used within the telephone, facsimile, pager and mobile elements. It is used to store the specific telephone number component of the corresponding telephony number. The data is entered as a string of up to ten characters.
interest | The interest learner information is one of the eleven core data structures. It contains the descriptive information and the products of the hobbies and recreational activities of the learner.
interpretscore | The interpretscore element is used within the result element to define the context for the associated evaluation scores. Typical uses for this element are to define the maximum or minimum possible scores for the test, etc. The interpretscore element contains the fieldlabel and fielddata elements that are used to define the vocabulary for the fields and the data entry itself respectively.
keyfields | The keyfields element is used within the securitykey element only. It is used to contain the actual description of the security information using one or more occurences of the element. The content is described using the fieldlabel and fielddata elements.
language | The language element is used within the accessibility element. It is used to contain the descriptions of the language proficiencies of the learner. The actual proficiencies are stored within the proficiency element. The actual language is defined using the typename element.
lat | The lat element is used to hold the longitude component of the geo element. The latitude is defined by three numbers i.e. degrees (0-89), minutes (0-59) and seconds (0-59), and the corresponding North/South (‘N’ or ‘S’) character.
learnerinformation | The learnerinformation data structure is the root element and is used to encapsulate the eleven core learner information classes. The control information describing the learner information as a whole is contained within the contentype structure - this defines the default values to be applied in general to all of the data objects (the definitions for the data objects themselves take precedence over these global values). The attribute xml:lang is used to define the default language of the full data structure.
level | The level element is used within the qcl element only. It is used to store the level of the associated qualification, certification or licence. The level element is recursive and so the grade of the award can be multi-faceted. The actual level is entered using the text element.
locality | The locality element is used within the address element to store the locality part of an address. The locality of an address refers to the immediate geographic area around the street or complex. This could be the parish, the county, etc. The data is entered as a string of up to 128 characters. The attribute xml:lang is used to define the language of the associated string entry.
lon | The lon element is used to hold the longitude component of the geo element. The longitude is defined by three numbers i.e. degrees (0-359), minutes (0-59) and seconds (0-59), and the corresponding East/West (‘E’ or ‘W’) character.
long | The long element is used within the description element. This element is used to contain a long character string (i.e. 256-2048 characters) that is used to characterise the associated description material. The long entry is used in conjunction with the optional short and full elements. The attribute xml:lang is used to define the language of the associated string entry.
media | The media element is used within the objectives and full elements. It is used to store the actual electronic materials e.g. text, video, images, etc. The nature of the content is defined using the mediamode, contentreftype and mimetype attributes. The electronic content can be embedded between the media element tags or it can be externally referenced.
mediamode | The mediamode attribute is used by the media element only. It is used to define the type of media that is to be stored. The mediamode attribute entry is required. The enumerated list consists of ‘Text’, ‘Video’, ‘Audio’, ‘Image’, ‘Applet’ and ‘Application’.
mimetype | The mimetype attribute is used by the media element only. It is used to define the type of material contained within the media element. The mimetype value takes the form as defined in RFC1521 e.g. ‘image/gif’, ‘video/mpeg’, etc. Each media element must define the associated mimetype.
mobile | The mobile element is used within the contactinfo element. This element is used to store the appropriate mobile telephone number. The telephone number can include the county code as well as the normal area code and the actual number.
name | The name element is used within the identification element. It is used to store the appropriate name of the learner. Each name is exchanged using its own name element. The name is entered through its component parts i.e. using the partname element. In general a name will have several parts. The type of name is defined using the typename element e.g. ‘Contact’, ‘Full’, etc.
nonfieldedstreetaddress | The nonfieldedstreetaddress element is used within the street element which itself is a part of the address element. This is used to store the unformatted name of the street cf. the relationship between the formname and name elements. The unformatted street entry can include any information in any order and so it must be treated as a single piece of data. This information is entered as a string that can be up to 256 characters long. The attribute xml:lang is used to define the language of the associated string entry.
noofattempts | The noofattempts element is used within the evaluation element which itself is within the activity element. It is used to store the number of attempts the learner has made in completing the associated evaluation e.g. a multiple choice question. The data is entered as a integer in the range of 1-99.
objectives | The objectives element is the container for the description of the objectives of the evaluation. These objectives are defined with respect to the actor as defined by the view attribute. The objectives may or not be included within the evaluation part of the activity information.
organization | The organization element is used by several other elements. It is used to store the name of the organisation that is associated with the primary data object e.g. the organisation responsible for awarding the qualification – see the qcl element. The type of organisation is defined using the typename element and the name is stored within the description element.
pager | The pager element is used within the contactinfo element. This element is used to store the appropriate pager telephony number. The pager number can include the county code as well as the normal area code and the actual number.
partname | The partname element is used within the name element which itself is a part of the identification element. It is used to contain the components of a name i.e. the name is supplied in named parts such as the first name, middle name, last name, etc. Each part is identified using the typename element. The name part is entered using the text element.
placeofbirth | The placeofbirth element is used within the demographics element. It is used to store the place of birth of the learner. The information is entered as a string of up to 128 characters length. The attribute xml:lang is used to define the language of the associated string entry.
pobox | The pobox element is used within the address element within the identification element. It is used to store the PO Box number component of the address – if available. The information is entered as a string of up to 32 characters. The xml:lang attribute is used to define the language used for the information.
postcode | The postcode element is used within the address element within the identification element. It is used to contain the post-code, or zip code, component of the learner’s address. The xml:lang attribute is used to define the language used for the data.
prefcode | The prefcode element is used within the preference element. It is used to contain the actual preference. The content format of the element is unformatted i.e. it is defined as #PCDATA. The attribute xml:lang is used to define the language of the associated entry.
preference | The preference element is used within the accessibility element. It is used to store the learner’s physical, cognitive and technical preferences. The type of preference is defined using the typename element. The actual preference is stored using the prefcode element.
priority | The priority element is used by several other elements. It is used to store the defined priority, or relative importance, of the event defined within the data object. The data is entered as a string of up to 64 characters length e.g. “Primary”, “Secondary”, etc. The attribute xml:lang is used to define the language of the associated string entry.
privacy | All of the data relevant to the privacy, authenticity and integrity of the learner information is contained within the privacy element. The actual privacy etc. mechanism and architectures used to support the learner information are outside of the scope of the specification but they interact with the learner information through these structures. The privacy information is defined for every data object that has an associated contentype element. The type of privacy information is defined using the typename element.
product | The product element is used within the interest and activity elements. It is used to store the electronic versions of the actual materials produced by the learner. The materials are stored using the description element and so explanatory information about the material can also be stored. The appropriate dates can also be stored. The type of product is defined using the typename element.
profmode | The profmode attribute is used by the proficiency element only. It is used to define the nature of the language proficiency i.e. write, read or oral (speaking and comprehending). This is an enumerated list and the attribute must be used.
proficiency | The proficiency element is used within the language element which is itself within the accessibility element. It is used to store the descriptions of the language proficiencies of the learner. The language proficiencies are stored as strings of up to 1024 characters length. The type of proficiency (write, read, oralspeak, oralcomp) is defined using the profmode attribute and the type of language is defined using the xml:lang attribute.
qcl | The qcl learner information is one of the eleven core data structures. It consists of the qualifications, certifications and licenses awarded to the learner i.e. the formally recognised products of their learning and work history. This includes information on the awarding body and may also include electronic copies of the actual documents. Each qcl is contained within its own XML instance.
recdata | The recdata element is used within the exrefrecord element only. It is used to contain information whose format has been defined by the recformat element. The optional uri attribute is used to define an external file that contains the actual data. The data entry can take any form between the tags.
recformat | The recformat element is used within the exrefrecord element only. It is used to define the format of the data to be stored within the recdata element. The optional uri attribute is used to define an external file that contains the actual data. The data entry can take any form between the tags.
referential | The referential information is used to uniquely identify the learner information record as a whole (sourcedid) and the individual data components (indexid) within that record. These enable each piece of information to be identified. The actual identification system is outside the scope of this specification. The referential information is defined for every data object that has an associated contentype element.
region | The region element is used within the address element only. This element is used to contain the region parts of an address e.g. ‘Europe’, ‘South America’, etc. An address may or may not contain an associated region part. The attribute xml:lang is used to define the language of the associated string entry.
registrationno | The registrationno element is used within the qcl element only. It is used to store the formal identifier assigned to the qualification, certification or licence by the awarding body. This identifier can be assumed to be unique with respect to the awarding organisation.
relationship | The relationship learner information is one of the eleven core data structures. It is a container for the definition of the relations between the other core data structures e.g. ‘qcl’s and the awarding organisation. This enables the construction of complex relationships between the core data structures. The basic structure is a one-to-one and one-to-many relationships. Many-to-many require the definition of several one-to-many relationships.
representation | The representation element is used within the demographics element which itself is used within the identification element. This element is used to store the materials that can be used to identify the learner e.g. photograph, voice-print, etc. The type of the representation material is defined using the typename element.
result | The result element is used within the evaluation element to store the scores associated with a particular activity. Each result can contain an arbitrarily complex data structure and so any set of scores can be exchanged. The result element also contains the interpretscore element which is used to describe the context of the scores e.g. maximum possible score, etc.
role | The role element is used within the affiliation element. It is used to store the roles undertaken by the learner as part of their affilitaion to an organisation. The type of role is defined using the typename element. The role informaton can also include the start of the appointment, the status and a description.
securitykey | The securitykey learner information is one of the eleven core data structures. It is used to store the descriptions of the passwords, encryption keys, PINs and authentication keys. These keys are used for transactions with the learner. A set of keys can be contained within each securitykey structure.
short | The short element is used within the description element. This element is used to contain a short character string (i.e. less than 80 characters) that is used to characterise the associated description material. The short entry is used in conjunction with the optional long and full elements but every usage of the description element should have an associated short entry. The attribute xml:lang is used to define the language of the associated string entry.
source | The source element is used within the sourcedid element. It is used to store the name/identifier of the organsiation responsible for the creation of the actual instance of the learner information being supplied. This name/identifier should be globally unique however the way this is achieved and policed is beyond the scope of this specification.
sourcedid | The sourcedid element is used within the referential element. It is used to assign a globally unique identifier to the associated data object. Each learner should be allocated a sourcedid that should be globally unique – how this is achieved is beyond the scope of this specification. All of the internal referencing mechanisms are defined with respect to the sourcedid assigned within the contentype data object associated with the learnerinformation element. The sourcedid consists of a source element and an id element. The source defines the organisation responsible for the allocation and/or creation of the identifier and the id the unique value with respect to that source. This sourcedid is the same as that defined in the IMS Enterprise specification.
sourcetype | The sourcetype attribute is used by the tysource element to define the nature of the source of the vocabulary. The possible values are: ‘imsdefault’ (defines the usage of the default IMS LIP vocabulary files whose name does not have to be supplied), ‘proprietary’ (defines the usage of a proprietary vocabulary file whose name is included as the content of the tysource element), ‘standard’ (defines the usage of an externally agreed standard vocabulary file whose name is included as the content of the tysource element) and ‘list’ in which the comma separated list is presented within the tysource element.
statepr | The statepr element is used within the address element only. This element is used to contain the name of the state/province/county part of the corresponding address. An address may or may not contain the name of the state/province/county. The attribute xml:lang is used to define the language of the associated string entry.
status | The status element is used within several other elements. It is used to contain the status of a particular data object e.g. the status of an activity, a goal, etc. The actual status is defined using the typename element and the associated date for the recording of the storage and a corresponding description is available.
street | The street element is used within the address element. It is used to contain the details of the street part of the full address. An address may or may not contain information about the street e.g. this may be unnecessary if a PO Box number has given.
streetname | The streetname element is used within the street element. This element is used to contain the name of the street that forms a part of the full address. An address does not have to contain a street name. The attribute xml:lang is used to define the language of the associated string entry.
streetnumber | The streetnumber element is used within the street element. This element is used to contain the house/residence/office number in the street part of the full address. An address does not have to contain a street number. The attribute xml:lang is used to define the language of the associated string entry.
streetprefix | The streetprefix element is used within the street element. This element is used to contain the prefix part of the street name e.g. ‘St’. An address does not have to contain a street prefix. The attribute xml:lang is used to define the language of the associated string entry.
streetsuffix | The streetsuffix element is used within the street element. This element is used to contain the suffix part of the street name e.g. ‘SW10’. An address does not have to contain a street prefix. The attribute xml:lang is used to define the language of the associated string entry.
streetype | The streetype element is used within the street element. This element is used to contain the type of street e.g. ‘Avenue’, ‘Road’, etc. An address does not have to contain a street type. The attribute xml:lang is used to define the language of the associated string entry.
telephone | The telephone element is used within the contactinfo element. This element is used to store the appropriate telephone number (not including mobile telephone numbers) cf. the facsimile element.. The telephone number can include the county code and extension number as well as the normal area code and actual number.
temporal | This information is used to describe any time-based dependencies of the data. This includes information such as the date of creation, time-stamp and expiry date of the learner information. The date/time descriptions are expected to conform to the ISO8601 standard. The temporal information is defined for every data object that has an associated contentype element.
temporalfield | The temporalfield element is used within the temporal element only. This element is used to contain the time related definitions that form a part of the content-type meta-data associated with each data object. Each entry is defined using the fieldlabel and fielddata elements.
testimonial | The testimonial element is used within the activity element. Throughout their lifetime, a learner will acquire many different testimonials. A testimonial is a statement of support from someone who has direct experience of the achievements and capabilities of the learner. A testimonial may be concerned with any aspect of the learner’s activities i.e. work-oriented, educational, recreational, civic, etc. The testimonial can contain any form of electronic content.
text | The text element is used to contain text entry data. This information can take the form of a single character or reference to an external text document. Two attributes are used by this element: xml:lang is used to define the language of the associated string entry, and uri defines the external file name identifier for the text file.
timezone | The timezone element is used within the address element. This element is used to store the time zone part of the address e.g. Greenwich Meridian Time (GMT), Eastern Daylight Time (EDT), etc. This information is supplied as a string entry and as such the xml:lang attribute is used to define the language of the entry.
title | The title element is used within the qcl element. This element is used to contain the formal title of the associated qualification, certification or license. A qcl entry may or may not have its title supplied. The attribute xml:lang is used to define the language of the associated string entry.
transcript | The transcript learner information is one of the eleven core data structures. It contains the summary record of the academic performance of an individual with respect to a particular institution. The transcript is normally supplied by the body responsible for evaluating of the performance of the individual. Each transcript is held within its own data structure.
tuple | The tuple element is used within the relationship element (one of the eleven core data structures). Each tuple is defined as a one-to-one or one-to-many relationship; many-to-many relationships require the definition of many tuples. Each tuple consists of a single source (tuplesource) the definition of the relationship (tuplerelation) and the one or more destinations (tupledest).
tupledest | The tupledest element is used within the tuple element. It is used to define the destination objects of the one-to-many relationship. The destination is defined either as a indexid or a combination of sourcedid and indexid. There is no requirement for the XML instance to contain the definition of the data objects whose relationship is being defined – the reconciliation of the reference identifiers is to be resolved by the communicating systems.
tuplerelation | The tuplerelation element is used within the tuple element to define the relationship between the tuplesource and the tupledest element contents. The actual relationship is defined by either using an agreed vocabulary, using the vocab element, or by explicit statement using the text element. Only one relationship is defined per tuple.
tuplesource | The tuplesource element is used within the tuple element. It is used to define the source object of the one-to-many relationship. The source is defined either as an indexid or a combination of sourcedid and indexid. There is no requirement for the XML instance to contain the definition of the data objects whose relationship is being defined – the reconciliation of the reference identifiers is to be resolved by the communicating systems.
typename | The typename element is used to support the extension of the default vocabularies used for the typing of the various data objects. Extensions to these vocabularies are supported through external reference to the corresponding file or through explicit statement of the typing.
tysource | The tysource element is used, when necessary, within the typename element. It is used to provide the vocabulary itself. The tysource element makes use of the sourcetype attribute to define if the associated entry is to be interpreted as a URI (external vocabulary reference) or text (the list of supported vocabulary itself).
tyvalue | The tyvalue element is used to define the selected entry within the available vocabulary. The xml:lang attribute is used define the language of the entry. The content of the vvalue element must be from the supplied vocabulary if the tysource element has been used in association with the tyvalue element.
uid | The uid element (referring to user identifier) is used within the demographics element. A learner may or may not provide a user identifier. A typical user identifier is a social security number, identity card number, etc. The information is supplied as a string entry.
units | The units element is used within the activity element. It is used to contain quantitative information associated with the value of the activity. This could include the credits for a course, a module, etc. The structure and vocabulary of the units are contained within the information held in the element itself.
unitsfield | The unitsfield element is used within the units element. Each unit is defined within its own unitsfield element and contains the definition of the field (using an appropriate vocabulary) and the data value itself. A combination of the fieldlabel and fielddata elements is used.
uri | The uri attribute is used by elements, such as vsource, to define the external reference file. This approach is used to define the external references or to provide links to media content such as images. The uri is defined as a string enclosed in quotation marks – the full directory path must be included.
view | The view attribute, applied to the objectives element, is used to define the ‘actors’ permitted to see the associated objectives. The supported actors are All (used to indicate access to all), Administrating Authority, Administrator, Assessor, Author, Candidate, Invigilator/Proctor, Psychometrician, Scorer and Tutor.
web | The web element is a part of the contactinfo element. It is used to store the web address of the learner. Multiple web addresses require the usage of multiple contactinfo instances. The information is supplied as string and should take the form of an ‘http’ reference as defined by W3C.
xml:lang | The xml:lang attribute is used wherever the language of the entry text can be varied. This attribute is used to define the language of the associated text. The format of the attribute shows that it is one of the core attributes provided by XML itself.