IMS Enterprise Information Model Version 1.1 Final Specification

Table of Contents

1. Introduction

1.1 Enterprise Specification Overview

The original IMS Enterprise V1.0 Specification was released in September 1999 with the errata V1.01 release following in December 1999 [Ent, 99a], [Ent, 99b], [Ent, 99c]. In August 2001 there was an IMS Enterprise Specification Validation meeting hosted by WebCT and held in Vancouver, Canada. At this meeting a review was held of the many successfully installed interoperable Enterprise systems based upon the IMS Enterprise Specification. The result of this meeting was the development and acceptance of the IMS Enterprise V1.1/V2.0 scoping document [Ent, 01].

The V1.1 IMS Enterprise Specification is fully backwards compatible with the V1.01 Specification1. The core amendments for this version are:

• Support for a number of the proprietary extensions used to extend interoperability for the v1.01 release. These extensions cover the <person>, <group> and <membership> data objects;
• Support for multiple <sourcedid> and <userid> structures. Password support has been added to the <userid> structure;
• Provision of enumerated non-numeric vocabularies. V1.0 uses numeric-based vocabularies. Wherever possible the vocabularies are to be extended to reflect common usage;
• 'Internationalization' of the core data objects including:
  • Name structure to support non-English conventions
  • Telephony and electronic contact numbers to be extended.

1.2 Scope & Context

This document is the IMS Enterprise Information Model V1.1 Final Specification document. As such it will be used as the basis for the development of the following documents:

• IMS Enterprise XML Binding v1.1 [Ent, 02a];
• IMS Enterprise Best Practice & Implementation Guide v1.2 [Ent, 02b].

This requirement has been derived from the agreed IMS Enterprise V1.1/2.0 Scoping document [Ent, 01].

1.3 Structure of this Document

The structure of this document is:

2. Specification Use-cases	The definition and scoping of the Enterprise systems and sub-systems that are to be supported by this specification;
3. Basic Information Model	The underlying Enterprise information model;
4. Conceptual Description of the Data Objects	The detailed description of the Enterprise data objects in terms of their elements, sub-elements and attributes;
5. Conformance	The definition of the conformance statement to be used by vendors.
Appendix A - Class Descriptions	The class descriptions of the <person>, group> and <membership> core data structures. These are supplied to act as a bridge to the UML based approach to be adopted in V2.0;
Appendix B - Summary of Changes in this Document	The details of all of the changes made for the production of this version of the specification document.

1.4 Nomenclature

API	Application Programming Interface
CBT	Computer Based Training
DTD	Document Type Definition
LMS	Learning Management System
UML	Unified Modelling Language
VLE	Virtual Learning Environment
W3C	World Wide Web Consortium
XML	Extensible Mark-up Language
XSD	XML Schema

1.5 References

[Ent, 01]	IMS Enterprise V1.1/V2.0 Scoping Document, C.Smythe, G.Collier and C.Etesse, IMS, November 2001.
[Ent, 02a]	IMS Enterprise XML Binding V1.1 Final Specification, C.Smythe, G.Collier and C.Etesse, IMS Specification, July 2002.
[Ent, 02b]	IMS Enterprise Best Practice & Implementation Guide V1.1 Final Specification, C.Smythe, G.Collier and C.Etesse, IMS Specification, July 2002.
[Ent, 99a]	IMS Enterprise Information Model V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[Ent, 99b]	IMS Enterprise XML Binding V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[Ent, 99c]	IMS Enterprise Best Practice & Implementation Guide V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[IMS, 01a]	IMS Persistent Location-independent Resource Identifier Implementation Handbook, V1.0, M.McKell, IMS Specification, May, 2001.

2. Specification Use Cases

2.1 Use Cases

The scope of information included in this version of the specification is intended to support interoperability between Learning Management Systems (LMS) and the following classes of Enterprise Systems:

• Human Resource Systems track skills and competencies and define eligibility for training programs;
• Student Administration Systems support the functions of course catalog management, class scheduling, academic program registration, class enrollment, attendance tracking, grade book functions, grading, and many other education functions;
• Training Administration Systems support course administration, course enrollment, and course completion functions for work force training;
• Library Management Systems track library patrons, manage collections of physical and electronic learning objects, and manage and track access to these materials.

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 of the following four business process components, which typically require interaction between Learning Management systems and these types of Enterprise systems.

2.1.1 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.

2.1.2 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.

2.1.3 Enrollment Management

Enrollment management encompasses the initial creation of Group membership and various changes to that data over time. Examples of enrollment management include learner enrollment in courses and instructor assignment to courses.

2.1.4 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 LMSs or in the Enterprise system.

2.2 Basic Architecture

The basic architectural model for the Enterprise V1.1 Specification is shown in Figure 2.1.

In this architecture the scope of the IMS Enterprise Specification is shown as the dotted line. The scope of the interoperability is the data model of the objects being exchanged and not the associated behavioral model or the required communications infrastructure.

3. Basic Information Model

3.1 Core Data Objects

A schematic representation of the core data objects exchanged using the IMS Enterprise Specification is given in Figure 3.1.

The core objects are:

• Person - the individuals who are undertaking some form of study and/or group related activity e.g., they are members of a particular course. The personal structure only contains information that is used to identify the individual and that is needed in learning systems. It is not designed to be a data repository for all of the personal information about an individual;
• Group - a collection of objects related to learning activities or individuals. The group is a generic container used to define any set of related activities e.g., a tutor group, a class, a curriculum, etc. There is no restriction on how the Group and sub-group structures can be used with respect to containing other groups, persons, etc.;
• Group Membership - the membership structure is used to define the members of a Group. A member can be a Person or another Group. A Group or Person can be a member of any number of groups. The Group and the member are identified using their sourcedids.

An Enterprise XML instance is designed to contain any number of Person, Group and Membership structures but the order in which these can occur are limited to all of the Person objects, followed by all of the Group objects followed by all of the Membership objects.

3.2 Simple Messaging Model

The IMS Enterprise Specification contains a very simple messaging model that is assumed to underlie the exchange of the data between the communicating Enterprise systems. The basic data exchange mechanism is shown in Figure 3.2 in which the 'source' and 'target' Enterprise systems exchange an IMS Enterprise XML instance file. The XML instance consists of a message/bundle header (called <properties>) and the message/bundle data body (this contains the appropriate mixture of <person>, <group> and <membership> structures).

It is important to remember that the structure of the XML instance and the actual usage of XML has no bearing on how the same information is contained within the 'source' and 'target' Enterprise systems. It is simply an exchange interoperability representation of the data (the information that crosses the dotted line in Figure 3.2).

An underlying assumption in a message-based system is that the sequence of messages will, in general, refer to the same objects at different moments in time e.g., the 'creation' of a Person, the 'updating' of a person and eventually the 'deletion' of the Person record. This means that the objects must have a unique identifier and that this address/label is unique between the communicating systems (an object may have more that one identifier even between the same two systems). The IMS Enterprise Specification calls these identifiers the 'sourcedid' of the object and it consists of a 'source' (globally unique across all the Enterprise systems) and an 'id' (unique within the source Enterprise system).

The usage of the 'sourcedid' for labelling the objects being exchanged gives rise to the scenario shown in Figure 3.3. The consequence of this approach is that any object will have multiple identifiers depending on which part of the system is being considered i.e.

• The 'sourcedid' is the exchange identifier and will be unique to a particular source system;
• The local identifier within the source system. This could be a database record number, etc. The source system must maintain the local identifier mapping table between the local identifier and the 'sourcedid';
• The local identifier within the target systems. In general the local identifier in each target system will be different. It is the responsibility of the target systems to maintain the local mapping table between the 'sourcedid' and their local identifier.

4. Conceptual Description of the Data Objects

4.1 Underlying Structure of the Enterprise Package

The primary elements of the learner information are shown in Figure 4.1:

4.2 Extensions and Extensibility

A key requirement for the specification is its support, where appropriate, for extensions. These extensions take the form:

• Functional extensions - extensions that are included to ensure that users of the specification can add functionality that is otherwise excluded from the specification (in the following tabular descriptions these are denoted by the 'extension' data structure). Further versions of the specification make full commitment to ensure backwards compatibility with these features. Within the XML binding each of these extensions will be given a unique element name.

4.3 Enterprise Package Tabular Description

The tables in this Section provide a conceptual, informative description of the elements in the data objects. The columns in these tables refer to:

No:	The number of the data element. An element may be composed of sub-elements. The numbering scheme reflects these relationships.
Name:	The descriptive name of the element.
Explanation:	A brief functional description of the element.
Required:	Indicates if the element is required: M = Mandatory Element that must be included in the data object, if the element at the higher level is included; C = Conditional Element. Existence is dependent on values of other Elements; O = Optional Element.
Mult:	Multiplicity of the element: Blank = single instance; Number = maximum number of times the element is repeatable; n = multiple occurrences allowed, no limit; Repeatability of an element implies that all sub-elements repeat with the same element.
Type:	A description of formatting rules for the data element - the set of data types are listed in Table 4.7. Type includes the maximum length of the element: ID = element used to uniquely identify an object; Code = element value from a list of codes; Description = descriptive element, human language Flag = binary flag Enumerated = list of predefined non-numeric options i.e. the definitive list of objects The international character set specified by ISO 10646 will be used for all fields.
	The type will also include a description of the set of valid values for the sub-element:
	Coding schemes using numerical values;
	The set of values as defined in the Domain i.e. making it closed. The list of values cannot be extended to include values not defined in the specification. If there is a need for values not included in the domain set of values then the extension should be done defining a new element under the Extension element that is a part of each data object definition.
Note:	Additional descriptive information about the element.

In the following tables the data objects are organized as:

• Table 4.1 - the 'enterprise' data structure i.e. the structure that constitutes the enterprise package itself;
• Table 4.2 - the 'person' data structure;
• Table 4.3 - the 'group' data structure;
• Table 4.4 - the 'membership' data structure;
• Table 4.5 - the common data structures (these are used within more than one of the above data structures);
• Table 4.6 - the functional extensions, <extension>, that are supported;
• Table 4.7 - the set of data types used within the tabular descriptions.

4.3.1 Enterprise Data Objects

Table 4.1 describes the data objects that are used in the construction of the IMS Enterprise package itself.

No	Name	Explanation	Reqd	Mult	Type	Note
1.1	comments	A container for comments about the full data structure.	O		See structure 5.1.
1.2	properties	The container of the basic packaging information that is used to manage the exchange of the data between the source and target systems.	M
1.2.1	lang	Default language of the text information provided in the attached objects.	O		See structure 5.2.
1.2.2	comments	A container for comments about the properties data structure.	O		See structure 5.1.
1.2.3	datasource	An identifier for the source system.	M		See structure 5.3.
1.2.4	target	An identifier for the target system.	O	n	string256	If the data objects are intended for one or more specific target systems, this element identifies those systems. Uses the same system naming scheme as is used for the data source.
1.2.5	type	Describes the type of event that caused the source system to generate the data objects.	O		string32	A standard set of codes must be agreed upon for specific implementations. Examples are: - Initial group creation - Group maintenance - Full group membership - Membership changes - Final grades
1.2.6	datetime	Date and time the data objects were generated by the data source.	M		See structure 5.4.
1.2.7	extension	The proprietary extension facility for the <proprietary> data object.	O		See structure 6.1.
1.3	person	The container for all of the data about a particular individual.	O	n	See Table 4.2.
1.4	group	The container for all of the information about a group and its relationships to other groups.	O	n	See Table 4.3.
1.5	membership	The container for all of the information about the members (as defined in a Person structure) in a particular Group.	O	n	See Table 4.4.

4.3.2 'person' Data Objects

Table 4.2 describes the data objects that are used in the construction of the summary results information.

No	Name	Explanation	Reqd	Mult	Type	Note
2.1	recstatus	Defines the type of operation that is required i.e. indicates that a Person has been added, updated or deleted.	O		See structure 5.5
2.2	comments	A container for comments about the full Person structure.	O		See structure 5.1.
2.3	sourcedid	The ID of the Person as defined by the source system.	M	n	See structure 5.6.
2.4	userid	The person's user ID to access the learning management environment.	O	n	See structure 5.9.
2.5	name	The name of the Person.	M			Note that the name parts specified below are to support interoperability, not to maintain a full record of a person's name.
2.5.1	fn	Formatted name.	M		string256	Examples include: Robert Jones Shirley R.Smith Jr. Ling Pao Basten Holter
2.5.2	sort	Name "parsed" and re-ordered to sort appropriately on an alphabetized report or outline panel (this name is not displayed: only used for sorting).	O		string256	Parsing schemes will be vendor specific.
2.5.3	nickname	Full name formatted in the way that the Person prefers to be addressed.	O		string256
2.5.4	n	Name with all parts distinguished.	O
2.5.4.1	family	This is the family name and not the last name.	O		string256	Jones
2.5.4.2	given	The given name and not necessarily the first name.	O		string256	Robert
2.5.4.3	other	Other name parts.	O	n	string256	This field is being deprecated in favour of the <partname> field.
2.5.4.4	prefix	Name prefix.	O		string32	Mr, Mrs, Ms, Dr, etc.
2.5.4.5	suffix	Name suffix.	O		string32	Jr, Snr, III, etc.
2.5.4.6	partname	The name supplied in its typed component parts.	O	n	string256
2.5.4.6.1	lang	Default language of the part name component.	O		See structure 5.2.
2.5.4.6.2	partnametype	The type component of the name.	M		string64	Examples of this open vocabulary include: 'Last', First', 'Middle', 'Maternal', 'Paternal', 'Initials', etc.
2.6	demographics	Demographic information about the person.	O			Minimal demographic information is specified.
2.6.1	gender	Gender of the Person.	O		string1 Enumerated as: 0=Unknown 1=Female 2=Male
2.6.2	bday	Date the person was born.	O		datetime
2.6.3	disability	An indication of the disability category of the individual.	O	n	string32	This information is NOT used to define the computer-based preferences of the Person.
2.7	email	E-mail address used to contact a Person.	O		See structure 5.7.
2.8	url	The Web address of the Person.	O		See structure 5.8.
2.9	tel	The telephone number used to contact the Person.	O	n	string32	International format should be used. An appropriate standard has not yet been agreed.
2.9.1	teltype	Indicates what type of phone number is being specified.	O		string8 Enumerated as: 1=Voice 2=Fax 3=Mobile 4=Pager Voice Fax Mobile Pager
2.10	adr	Address used to deliver physical objects to a person.	O			Only one address is supported.
2.10.1	pobox	Post Office Box.	O		string32
2.10.2	extadd	Extra address space.	O		string128	Any non-street components of the address e.g., suite number, company name, etc.
2.10.3	street	Street address.	O	3	string128
2.10.4	locality	Locality.	O		string64	City is one example of locality.
2.10.5	region	Region.	O		string64	State and Province are examples of region.
2.10.6	pcode	Postal code.	O		string32	This format varies from country to country.
2.10.7	country	Country.	O		string64	Codes specified in ISO3166.
2.11	photo	Reference to an external location containing a photo of the person.	O
2.11.1	imgtype	The type of image referenced.	O		string32	Should contain the MIME type e.g., image/bmp, image/jpg, etc.
2.11.2	extref	The reference to an external location.	M		string1024	Could be a URL.
2.12	systemrole	The role of the Person within the software environment.	O
2.12.1	systemroletype	The type of role that the Person is permitted within the software environment.	M		string32 Enumerated as: SysAdmin SysSupport Creator AccountAdmin User Administrator None
2.13	institutionrole	The role of the Person within the institution.	O	n
2.13.1	primaryrole	Identifies if the associated role is the primary one for the Person in the institution.	M		string4 Enumerated as: Yes No
2.13.2	institutionroletype	The type of role that the Person has within the institution supporting the learning activity.	M		string32 Enumerated as: Student Faculty Member Learner Instructor Mentor Staff Alumni ProspectiveStudent Guest Other Administrator Observer
2.14	datasource	An identifier of the source system of the Person object.	O		See structure 5.3.
2.15	extension	The proprietary extension facility for the Person object.	O		See structure 6.2.

4.3.3 'group' Data Objects

Table 4.3 describes the data objects that are used in the construction of the detailed assessment results.

No	Name	Explanation	Reqd	Mult	Type	Note
3.1	recstatus	Defines the type of operation that is required i.e. indicates that a Group has been added, updated or deleted.	O		See structure 5.5
3.2	comments	A container for comments about the full Group structure.	O		See structure 5.1.
3.3	sourcedid	The ID of the Group as defined by the source system.	M	n	See structure 5.6.
3.4	grouptype	Defines the type of Group.	O	n		This element provides a structure that allows a Group to be categorized into one or more coding schemes, with any number of levels supported within each scheme.
3.4.1	scheme	Group type coding scheme.	O		string256	Identifies which Group categorization scheme is being used. This could be a proprietary vendor taxonomy, a national subject are taxonomy, etc.
3.4.2	typevalue	Group type code value.	M	n	string256	Repeats to allow more than one level of code to be stored. The value at this level. An example of the Level/value interaction might be: Lvl 1 - Instruction Lvl 2 - Discussion Group Lvl 3 - Web enabled
3.4.2.1	level	Group type code level.	M		string2	Level 1 is the highest level, level 2 provides a further refinement of the level 1 category, etc.
3.5	description	Description/name of the Group.	M
3.5.1	short	Intended to be displayed on screen on less than one line.	M		string60	Usually something brief such as "ENGLISH 101A SECTION 4".
3.5.2	long	Longer descriptive name for the Group.	O		string256	"English 101A - Great Authors of the 19th and 20th Century".
3.5.3	full	A longer description of the Group.	O		string2048	For example the "catalog" description of a course.
3.6	org	The organization administering or 'sponsoring' the Group.	O			For example Cal State San Marcos would be the administrator of a course section offered on their campus.
3.6.1	orgname	The name of the organization.	O		string256	'Cal State San Marcos'.
3.6.2	orgunit	Name of the sponsoring or administering unit within the organization.	O	n	string256	One or more departments or units can sponsor the Group e.g., '0-158 - Math Department'.
3.6.3	type	Used to distinguish general categories of the organization.	O		string32	'Academic Unit' 'HR Department'.
3.6.4	id	Identifier of the organization.	O		string256	If there is a code for the organization, it can be specified separately in this field.
3.7	timeframe	Time frame when the Group is active.	O		See structure 5.10.
3.8	enrollcontrol	The container for the enrolment control data.	O
3.8.1	enrollaccept	Indicates if the Group is accepting enrolments.	O		integer1 Enumerated as: 0=No 1=Yes	There can be different reasons for a Group being closed. It may be full; it may be cancelled.
3.8.2	enrollallowed	Determines if the target system can enrol people.	O		integer1 Enumerated as: 0=No 1=Yes	If No, then only the source system can enrol people.
3.9	email	E-mail address for contacting all members of a Group.	O		See structure 5.7.
3.10	url	URL for a Group.	O		See structure 5.8.
3.11	relationship	If the Group is related to another Group then this element can be used to describe that relationship.	O	n		This element should not be used to store "membership' in other Groups. The Group membership construct is used for that type of role-based membership.
3.11.1	relation	Defines the nature of the relationship.	O		string8 Enumerated as: 1=Parent 2=Child 3=Also known as Parent Child KnownAs	This field is used to define the relationship of this group (defined using the identifier in field 3.11.2, known as 'A') to the object Group (defined using the identifier 3.3, known as 'B'). The relationship is "A is the <relation> of B". Code '3' or 'KnownAs' is used to indicate that two Groups are really the same.
3.11.2	sourcedid	The unique identifier of the other Group with which the relationship is being established.	M		See structure 5.6.
3.11.3	label	Describes the nature of the relationship between this Group and the related Group.	M		string32	Examples are: 'Course sub-group' 'Cross-listed Course Section'.
3.12	datasource	An identifier of the source system of the Group object.	O		See structure 5.3.
3.13	extension	The proprietary extension facility for the Group object.	O		See structure 6.3.

4.3.4 'membership' Data Objects

Table 4.4 describes the data objects that are used in the construction of the detailed section results.

No	Name	Explanation	Reqd	Mult	Type	Note
4.1	comments	A container for comments about the full Membership structure.	O		See structure 5.1.
4.2	sourcedid	The ID of the Group as defined by the source system. The memberships are defined with respect to this Group.	M		See structure 5.6.
4.3	member	Group member.	M	n
4.3.1	comments	A container for comments about the full Member structure.	O		See structure 5.1.
4.3.2	sourcedid	The ID of a Person or a Group as defined by the source system.	M		See structure 5.6.
4.3.3	idtype	Indicates if the member is a Person or another Group.	M		integer1 Enumerated as: 1=Person 2=Group
4.3.4	role	The role of the member in the Group.	M	n		A member can have multiple roles in a Group e.g., Learner and Instructor. These would be reflected in separate occurrences of the <role> element.
4.3.4.1	recstatus	Defines the type of operation that is required i.e. indicates that a Group Membership has been added, updated or deleted.	O		See structure 5.5
4.3.4.2	roletype	The member's function within a Group.	O		string32 Enumerated as: 01=Learner 02=Instructor 03=Content Developer 04=Member 05=Manager 06=Mentor 07=Administrator 08=TeachingAssistant Learner Instructor Content Developer Member Manager Mentor Administrator TeachingAssistant
4.3.4.3	subrole	Further qualifies a member's role in the Group.	O		string32	For an Instructor role type some examples are: Primary Instructor Tutor.
4.3.4.4	status	Indicates if a member is active or inactive in the Group.	M		integer1 Enumerated as: 0=Inactive 1=Active	This allows the source system to specifically tell the target system that a member is now active or inactive. Another view is that the absence of a membership record when membership data is passed implies inactivity and the existence of a record implies active membership. This will logically work for a 'snap-shot' interface where all members are passed every time objects are passed from one system to another but it will not support an interface where individual membership records are passed.
4.3.4.5	userid	Person's user ID to access the Group for this role.	O		See structure 5.9
4.3.4.6	comments	Description of the current status.	O		See structure 5.1.
4.3.4.7	datetime	Date the current membership status was established.	O		See structure 5.10.1.1
4.3.4.8	timeframe	Time frame of membership in the Group.	O		See structure 5.10.
4.3.4.9	interimresult	Interim result codes and value.	O	n		The specification allows for the passing of a group member's interim result mode and all valid interim result values from the source system to the target system. It is provided at the Group member level because it can vary for different members of a Group. The specification also allows for the passing of a Group member's interim result, both a result code and result description. This structure is to be deprecated in V2.0.
_1	resulttype	The type of the interim result.	O		string32	Examples are: 'Mid-term' 'Part I' etc.
_2	mode	Short descriptive name for interim result grading mode.	O		string32	Examples are: 'Letter Grade' 'Pass/Fail' 'Percentage' etc.
_3	values	Valid interim result values.	O			Used to tell the target system what interim result values are valid to assign to a learner.
_3.1	valuetype	Indicates if the values are a list of specific codes or a numeric range.	M		integer1 Enumerated as: 0=List 1=Range	Tells the system to use either the list or the Min/Max values.
_3.2	list	A specific interim result value.	C	n	string32	The list contains the valid grades if valuetype=0.
_3.3	min	Minimum numeric value allowed for an interim result.	C		decimal8p4	Used if valuetype=1.
_3.4	max	Maximum numeric value allowed for an interim result.	C		decimal8p4	Used if valuetype=1.
_4	result	Value of interim result assigned to the member for participation in the Group.	O		string32	Ideally this would be one of the values from the results values list e.g., A+, 85%, Completed, etc.
_5	comments	Comments about the interim result.	O		See structure 5.1.
4.3.4.10	finalresult	Final result codes and value.	O	n		The specification allows for the passing of a group member's final result mode and all valid result values from the source system to the target system. It is provided at the Group member level because it can vary for different members of a Group. The specification also allows for the passing of a Group member's final result, both a result code and result description. This structure is to be deprecated in V2.0.
_1	mode	Short descriptive name for final result grading mode.	O		string32	Examples are: 'Letter Grade' 'Pass/Fail' 'Percentage' etc.
_2	values	Valid result values.	O			Used to tell the target system what final result values are valid to assign to a learner.
_2.1	valuetype	Indicates if the values are a list of specific codes or a numeric range.	M		integer1 Enumerated as: 0=List 1=Range	Tells the system to use either the list or the Min/Max values.
_2.2	list	A specific result value.	C	n	string32	The list contains the valid grades if valuetype=0.
_2.3	min	Minimum numeric value allowed for a result.	C		decimal8p4	Used if valuetype=1.
_2.4	max	Maximum numeric value allowed for a result.	C		decimal8p4	Used if valuetype=1.
_3	result	Value of final result assigned to the member for participation in the Group.	O		string32	Ideally this would be one of the values from the results values list e.g., A+, 85%, Completed, etc.
_4	comments	Comments about the final result.	O		See structure 5.1.
4.3.4.11	email	E-mail address used to contact a member for information related to a specific Group membership.	O		See structure 5.7.
4.3.4.12	datasource	An identifier of the source system of the Member.	O		See structure 5.3.
4.3.4.13	extension	The proprietary extension facility for the Role object.	O		See structure 6.4.

4.3.5 Common Data Objects

Table 4.5 describes the common data objects that are used to support the other data objects.

No	Name	Explanation	Reqd	Mult	Type	Note
5.1	comments	Comments about the containing data structure.