IMS Enterprise Information Model Version 1.1 Final Specification

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 © 2002 IMS Global Learning Consortium. All Rights Reserved.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

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

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.	-	-	string2048
5.1.1	lang	The written language for the comment.	O		As per structure 5.2.
5.2	lang	The written language for the string.	-	-	string128	The vocabulary is taken from ISO639.
5.3	datasource	An identifier for the original source of the information.	-	-	string256	Allows the target system(s) to identify the system that generated the data objects. The value must be unique for each source.
5.4	datetime	Date and time the data objects were generated.	-	-	datetime	Based upon ISO8601.
5.5	recstatus	The Record status i.e. the type of transaction being instigated.	-	-	integer1 Enumerated as: 1=Add 2=Update 3=Delete	In an event driven interface this flag can be passed from the source to the target system to indicate that the object has been added, updated or deleted. If this field is not present the target should interpret the behavior as 'Add' or 'Update'.
5.6	sourcedid	The ID of the data object defined by the source.	-	-
5.6.1	sourcedidtype	The type of sourcedid.	O		string16 Enumerated as: New Old Duplicate	This is used to enable objects to have their sourcedid altered. The combination of 'New' and 'Old' is used to change a <sourcedid>. The 'Duplicate' value is used to imply the redundant object.
5.6.2	source	Identifier of the organization or system that assigned the ID.	M		string32
5.6.3	id	Permanently unique identifier of the object as defined by the system where the object was created.	M		string256
5.7	email	E-mail address used to contact a Person or Group.	-	-	string256
5.8	url	The Web address of the Person or Group.	O		url	This should be the Absolute URL i.e. include the 'http://'.
5.9	userid	The person's user ID to access the learning management environment.	_	_	string256	This must not be used to contain password information. Any implementation of this specification must ensure the security of this, and all, data.
5.9.1	useridtype	The type of user identification.	O		string32	Some example values are 'NationalId' or 'InstitutionId'.
5.9.2	password	The password that is assigned to the user for accessing a system.	O		string1024
5.9.3	pwencryptiontype	The type of encryption that has been applied to the password.	O		string32	Example values include 'PKC' and 'MD5'.
5.9.4	authenticationtype	The type of authentication that is to be applied to the system access.	O		string32	Example values include 'Kerberos', etc.
5.10	timeframe	Time frame when the Group is active.	-	-
5.10.1	begin	Defines when the core object is intended to be available for participation. Date of availability.	O		date	Based upon the date structure of ISO8601.
5.10.1.1	restrict	Defines if learner participation is permitted before the start date.	M		integer1 Enumerated as: 0=No 1=Yes
5.10.2	end	Defines when the core object availability is intended to end. Date of availability.	O		date	Based upon the date structure of ISO8601.
5.10.2.1	restrict	Defines if learner participation is permitted after the end date.	M		integer1 Enumerated as: 0=No 1=Yes
5.10.3	adminperiod	Short descriptive name in human readable form for the administrative or academic period within which the group exists.	O		string32	For example: '- 1999' '-Fall 1999' etc.

4.3.6 'extension' Definitions

Table 4.6 list the set of extension names that are used within the XML binding. These names are mapped to the 'extension' element used within Tables 4.1 to 4.5 of the Information Model.

No	Name	Explanation	Reqd	Mult	Type	Note
6.1	extension	The proprietary extension facility for the <properties> structure.	-	-	ANY
6.2	extension	The proprietary extension facility for the <person> structure.	-	-	ANY
6.3	extension	The proprietary extension facility for the <group> structure.	-	-	ANY
6.4	extension	The proprietary extension facility for the <role> structure.	-	-	ANY

4.3.7 Data Types

Table 4.7 present the definitions of the data-type used within the tabular description of the information data model.

Data-type	Description
string1	String of characters of length [1]
string2	String of characters of length [1-2]
String4	String of characters of length [1-4]
string8	String of characters of length [1-8]
string32	String of characters of length [1-32]
string60	String of characters of length [1-60]
string64	String of characters of length [1-64]
string128	String of characters of length [1-128]
string256	String of characters of length [1-256]
string1024	String of characters of length [1-1024]
string2048	String of characters of length [1-2048]
integer1	Integer in the range [0-9] supplied as a single character.
decimal8p4	Real number in the range [0-9999.9999] supplied as a string of characters [1-9]
datetime	String of characters [1-20] in ISO8601 format i.e. YYYY-MM-DDTHH:MM:SS
date	String of characters [1-10] in ISO8601 format i.e. YYYY-MM-DD
url	String of characters [1-1024] in Absolute URL format

5. Conformance

The purpose of this statement is to provide a mechanism for customers to fairly compare vendors of Enterprise systems and sub-systems. It is not mandatory for a vendor to support every feature of the Enterprise specification, but a vendor must detail their level of support with a "Conformance Statement". Compliance is represented by:

• Conformance summary - this is a summary that shows, in colloquial terms, the capabilities of a particular implementation with respect to the IMS Enterprise Specification;
• Interoperability statement - this is a detailed technical checklist that identifies all of the feature capabilities of the implementation in terms of the IMS Enterprise Specification functions.

5.1 Valid Data Issues

Vendors claiming conformance shall be able to read and write valid instances of the Enterprise data as defined by the XML Schema including proprietary extensions where applicable. For the handling of an IMS Enterprise 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 Enterprise specification have been used and/or required.

5.2 Conformance Summary

Vendors claiming conformance must provide a "Conformance Summary", detailing their level of conformance, substantially similar to the information shown below, upon a reasonable request from a member of the IMS, or a prospective customer(s). It is expected that this table, a template of which is shown in Table 5.1, is a summary of the information given in the 'Interoperability statement'. The intention is for the 'Conformance Summary' to be informative in nature.

	Enterprise Conformance Summary (Version 1.1)
	Publish	Accept
properties	Y or N	Y or N
person	Y or N	Y or N
recstatus	Y or N	Y or N
sourcedid	Y or N	Y or N
userid	Y or N	Y or N
name	Y or N	Y or N
demographics	Y or N	Y or N
email	Y or N	Y or N
url	Y or N	Y or N
tel	Y or N	Y or N
adr	Y or N	Y or N
photo	Y or N	Y or N
systemrole	Y or N	Y or N
institutionrole	Y or N	Y or N
datasource	Y or N	Y or N
group	Y or N	Y or N
recstatus	Y or N	Y or N
sourcedid	Y or N	Y or N
grouptype	Y or N	Y or N
description	Y or N	Y or N
org	Y or N	Y or N
timeframe	Y or N	Y or N
enrollcontrol	Y or N	Y or N
email	Y or N	Y or N
url	Y or N	Y or N
relationship	Y or N	Y or N
datasource	Y or N	Y or N
membership	Y or N	Y or N
sourcedid	Y or N	Y or N
member	Y or N	Y or N
sourcedid	Y or N	Y or N
role	Y or N	Y or N
recstatus	Y or N	Y or N
subrole	Y or N	Y or N
status	Y or N	Y or N
userid	Y or N	Y or N
datetime	Y or N	Y or N
timeframe	Y or N	Y or N
interimresult	Y or N	Y or N
finalresult	Y or N	Y or N
email	Y or N	Y or N
datasource	Y or N	Y or N

Completion of the two columns is intended to reflect:

• Publish - this implies that the XML instance contains the identified elements. If such an element is not ticked then it will not occur within the exported Enterprise instance(s);
• Accept - it is assumed that the ability to accept the contents of an element is accompanied by the ability to use, and if appropriate, display that content.

5.3 Interoperability Statement

An example of the detailed 'Interoperability Statement' is shown in Tables 5.2a, 5.2b, 5.2c and 5.2d (one for each of the core structures). Compliance to Enterprise means that at least one of the columns must be completed.

properties		Version 1.1
Mandatory: This structure is mandatory i.e. it MUST be used in any IMS Enterprise XML instance.
q datasource
q datetime
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
	Publish	Accept	Notes
comments	q	q
target	q	q
type	q	q
lang	q	q
Extension Fields: These features allow the data model to be extended.
	Publish	Accept	Notes
	None	None

person		Version 1.1
Mandatory:
q sourcedid
q name   q fn
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
	Publish	Accept	Notes
recstatus	q	q
comments	q	q
userid	q	q
name	-	-
sort	q	q
nickname	q	q
n	q	q
family	q	q
given	q	q
other	q	q
prefix	q	q
partname	q	q
demographics	q	q
gender	q	q
bday	q	q
disability	q	q
email	q	q
url	q	q
tel	q	q
adr	q	q
pobox	q	q
extadd	q	q
street	q	q
locality	q	q
region	q	q
pcode	q	q
country	q	q
photo	q	q
extref	-	-
imgtype	q	q
systemrole	q	q
institutionrole	q	q
datasource	q	q
Extension Fields: These features allow the data model to be extended.
	Publish	Accept	Notes
extension	q	q

Group		Version 1.1
Mandatory:
q sourcedid
q description   q short
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
	Publish	Accept	Notes
recstatus	q	q
comments	q	q
grouptype	q	q
scheme	q	q
typevalue	-	-
level	-	-
value	-	-
description	-	-
short	-	-
long	q	q
full	q	q
org	q	q
orgname	-	-
orgunit	q	q
type	q	q
id	q	q
timeframe	q	q
begin	q	q
date	q	q
restrict	q	q
end	q	q
date	q	q
restrict	q	q
adminperiod	q	q
enrollcontrol	q	q
enrollaccept	q	q
enrollallowed	q	q
email	q	q
url	q	q
relationship	q	q
relation	q	q
sourcedid	-	-
label	-	-
datasource	q	q
Extension Fields: These features allow the data model to be extended.
	Publish	Accept	Notes
extension	q	q

membership		Version 1.1
Mandatory:
q sourcedid
q member
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.
	Publish	Accept	Notes
comments	q	q
member	-	-
comments	q	q
sourcedid	-	-
idtype	-	-
role	-	-
recstatus	q	q
roletype	-	-
subrole	q	q
status	-	-
userid	q	q
comments	q	q
datetime	q	q
timeframe	q	q
begin	q	q
date	q	q
restrict	q	q
end	q	q
date	q	q
restrict	q	q
adminperiod	q	q
interimresult	q	q
resulttype	q	q
mode	q	q
values	q	q
valuetype	-	-
list	q	q
min	q	q
max	q	q
result	q	q
comments	q	q
finalresult	q	q
mode	q	q
values	q	q
valuetype	-	-
list	q	q
min	q	q
max	q	q
result	q	q
comments	q	q
email	q	q
datasource	q	q
Extension Fields: These features allow the data model to be extended.
	Publish	Accept	Notes
extension	q	q

Note that the 'Interoperability Statement' addresses support for the various elements within the binding. The set of attributes are not considered. Inclusion of conformance with respect to attributes will be considered in later versions of the specification.

It is important that the 'Interoperability Statement' is clear in showing what is and, perhaps more importantly, what is not supported. The usage of descriptive conformance approach has been adopted to encourage vendors to be as clear as possible when describing the capabilities of their Enterprise-compliant systems.

Appendix A - Class Descriptions

These class descriptions have been added to act as bridging information between the v1.1 and v2.0 information models. These are the core classes and no form of aggregation has been undertaken. The class descriptions are contained in tables A1, A2, A3, and A4. The form of the class descriptions includes:

• attribute - the name of the data component;
• type - the data type of the attribute;
• mult - the multiplicity of the occurrence of the attribute (O=optional, M=mandatory, O*=optional but many occurrences, M*=mandatory but many occurrences);
• constraint - any constraints that are to be applied to the possible values for the attributes.

A1 - Data Types

The data types used in the class descriptions are:

string1	String of characters [1]
string2	String of characters [2]
string4	String of characters [1-4]
string8	String of characters [1-8]
string32	String of characters [1-32]
string60	String of characters [1-32]
string64	String of characters [1-64]
string128	String of characters [1-128]
string256	String of characters [1-256]
string1024	String of characters [1-1024]
string2048	String of characters [1-2048]
integer1	Integer in the range [0-9]
decimal8p4	Real number in the range [0-9999.9999]
datetime	String of characters [1-20] in ISO8601 format
url	String of characters [1-1024] in URL format

A2 - Properties Class

The properties class is shown in Table A1.

properties
attribute	type	mult	constraint
-comments	string2048	O
-datasource:	string256	M
-target:	string256	O*
-type:	string32	O
-datetime:	datetime	M
-lang:	string128	O	Vocabulary - ISO639

A3 - Person Class

The properties class is shown in Table A2. All of the changes introduced in V1.1 are shaded.

person
attribute	type	mult	constraint
-recstatus	integer1	O	{1=Add, 2=Update, 3=Delete}
-comments	string2048	O
-lang	string128	O	Vocabulary - ISO639
-sourcedid		M*
-sourcedidtype	string16	O	{New, Old, Duplicate}
-source	string32	M
-id	string256	M
-userid	string256	O*
-useridtype	string32	O
-password	string1024	O
-pwencryptiontype	string32	O
-authenticationtype	string32	O
-name		M
-fn	string256	M
-sort	string256	O
-nickname	string256	O
-n		O
-family	string256	O
-given	string256	O
-other	string256	O*
-prefix	string32	O
-suffix	string32	O
-partname	string256	O*
-lang	string128	O	Vocabulary - ISO639
-partnametype		M
-demographics		O
-gender	string1	O	{0=Unknown, 1=Female, 2=Male}
-bday	datetime	O
-disability	string64	O
-email	string256	O
-url	url	O
-tel	string32	O4
-teltype	string8	O	{1=Voice, 2=Fax, 3=Mobile, 4=Pager, Voice, Fax, Mobile, Pager}
-adr
-pobox	string32	O
-extadd	string128	O
-street	string128	O3
-locality	string64	O
-region	string64	O
-pcode	string32	O
-country	string64	O	Vocabulary - ISO3166
-photo
-extref	string1024	M
-imgtype	string32	O
-systemrole		O
-systemroletype	string32	M	{SysAdmin, SysSupport, Creator, AccountAdmin, User, Administrator, None}
-institutionrole		O*
-primaryrole	string4	M	{Yes, No}
-institutionroletype	string32	M	{Student, Faculty, Member, Learner, Instructor, Mentor, Staff, Alumni, ProspectiveStudent, Guest, Other, Administrator, Observer}
-datasource	string256	O