IMS Logo IMS Enterprise Best Practice and Implementation Guide
Version 1.1 Final Specification
Copyright © 2002 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Enterprise Best Practice and Implementation Guide
Date: 01 July 2002

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
     1.2 Scope and 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 CEN/ISSS
     2.4 IMS Specification Development Process

3. Overall Data Model
     3.1 Core Data Objects
     3.2 Simple Transaction Model
     3.3 XML Schema
           3.3.1 Enterprise Root Structure
           3.3.2 Membership Data Object

4. Basic Example XML Instances
     4.1 Person Examples
           4.1.1 Create a Single Person Record
           4.1.2 Create Multiple Person Records
     4.2 Group Examples
           4.2.1 Create a Single Group Record
           4.2.2 Create Multiple Group Records
           4.2.3 Create Sub-Group Records
           4.2.4 Support for Cross-Listed Groups
     4.3 Membership Examples
           4.3.1 Create a Single Membership Record
           4.3.2 Create Multiple Membership Records

5. Advanced Example XML Instances
     5.1 A V1.0 Example Renovated in V1.1 Format
     5.2 A Course Catalog

6. IMS Enterprise and Other Specifications
     6.1 IMS Specifications
           6.1.1 IMS Learner Information Package (LIP) Mapping
     6.2 Other Specifications
           6.2.1 IETF vCard Mapping
           6.2.2 Internet2/Educause 'eduPerson' Mapping
           6.2.3 LDAP Attribute Mapping

7. Implementation Guidance
     7.1 Achieving Interoperability
           7.1.1 Interworking Enterprise Systems
     7.2 Architectural Considerations
           7.2.1 Interface Architectures
           7.2.2 Single File from Multiple Systems
           7.2.3 Addresses and Identifiers
     7.3 Using Person
     7.4 Using Group
           7.4.1 Groups and Sub-Groups
           7.4.2 Cross-Listed Course Sections
     7.5 Using Membership
           7.5.1 Assigning Group Membership Role-type
     7.6 IMS Harmonization
     7.7 Example Set

8. Proprietary Extensions

9. V1.0/V1.01/V1.1 Issues and Compatibility
     9.1 V1.1 Functional Additions
     9.2 V1.0/V1.01/V1.1 Compatibility
     9.3 V2.0 Specification and Compatibility

10. Conformance
     10.1 Valid Data Issues
     10.2 Conformance Summary
     10.3 Interoperability Statement
     10.4 Completing a Conformance Summary
     10.5 An Example Conformance Statement

Appendix A - Glossary of Terms

Appendix B - Summary of Changes

About This Document
     List of Contributors

Revision History

Index

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:

1.2 Scope and Context

This document is the second revised version of the IMS Enterprise Best Practice and Implementation Guide V1.1 Final Specification document. As such it should be used in conjunction with:

This requirement has been derived from the agreed IMS Enterprise V1.1/2.0 Scoping document [Ent, 01]. The contents of this document contain the accumulated wisdom on the best practices for using the IMS Enterprise Specification.

1.3 Structure of this Document

The structure of this document is:

2. Relationship to Other Specifications
The relationship of this specification activity to other IMS and external specification activities;
3. Overall Data Model
A brief summary of the IMS Enterprise information model;
4. Basic Example XML Instances
Examples of the basic Enterprise XML instances that are supported by this specification;
5. Advanced Example XML Instances
Examples of the advanced Enterprise XML instances that are supported by this specification;
6. IMS Enterprise and Other Specifications
The ways in which the IMS Enterprise functionality can be used to support common functionality in other similar specifications;
7. Implementation Guidance
Tips on how the distributed enterprise systems can make best usage of the IMS Enterprise Specification;
8. Proprietary Extensions
Usage of the extensions facilities to support proprietary requirements;
9. V1.0/V1.01/V1.1 Issues and Compatibility
The initial scoping of the version 1.x/2.0 specifications and IMS's commitment to backwards compatibility;
10. Conformance
The expectations on systems that claim conformance to the IMS Enterprise Specification;
Appendix A - Glossary of Terms
A glossary of the key terms and elements used within the specification.
Appendix B - Summary of Changes
The details of all of the changes made for the production of this version of the specification document.

1.4 Nomenclature

ADL
Advanced Distributed Learning
AICC
Aviation Industry CBT Committee
ANSI
American National Standards Institute
API
Application Programming Interface
CBT
Computer Based Training
DTD
Document Type Definition
EDI
Electronic Document Interchange
HRMS
Human Resources Management System
IEEE
Institute of Electronic & Electrical Engineering
IETF
Internet Engineering Task Force
ISO/IEC
International Standards Organization/International Electrotechnical Committee
JTC
Joint Technical Committee
LDAP
Lightweight Directory Access Protocol
LIP
Learner Information Package
LMS
Learning Management System
LTSC
Learning Technology Standards Committee
NATO
North Atlantic Treaty Organization
PAPI
Personal & Private Information
QTI
Question and Test Interoperability
SA
Student Administration
SCORM
Shareable Content Object Reference Model
SIF
Schools Interoperability Framework
SIS
Student Information System
VLE
Virtual Learning Environment
W3C
World Wide Web Consortium
XML
Extensible Mark-up Language
XSD
XML Schema

1.5 References

[CP, 01a]
IMS Content Packaging Information Model, T.Anderson, M.McKell, A.Cooper and W.Young, C.Moffatt, Version 1.1.2, IMS, August 2001.
[CP, 01b]
IMS Content Packaging XML Binding, T.Anderson, M.McKell, A.Cooper and W.Young, C.Moffatt, Version 1.1.2, IMS, August 2001.
[CP, 01c]
IMS Content Packaging Best Practice and Implementation Guide, T.Anderson, M.McKell, A.Cooper and W.Young, C.Moffatt, Version 1.1.2, IMS, August 2001.
[Ent, 01]
IMS Enterprise V1.1/V2.0 Scoping Document, C.Smythe, G.Collier and C.Etesse, IMS, November 2001.
[Ent, 02a]
IMS Enterprise Information Model Final Specification, C.Smythe, G.Collier and C.Etesse, IMS Specification, July 2002.
[Ent, 02b]
IMS Enterprise XML Binding 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 and 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.
[IMS, 01b]
Using the IMS Content Packaging to Package Instances of LIP and Other IMS Specifications Implementation Handbook, V1.0, B.Olivier and M.McKell, IMS Specifications, August 2001.
[LIP, 01a]
IMS Learner Information Package Information Model, 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 Packaging Best Practices and Implementation Guide Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.
[MD, 01a]
IMS Learning Resource Meta-data Information Model, T.Anderson and M.McKell, Version 1.2, IMS, May 2001.
[MD, 01b]
IMS Learning Resource Meta-data XML Binding, T.Anderson and M.McKell, Version 1.2, IMS, May 2001.
[MD, 01c]
IMS Learning Meta-data Best Practice and Implementation Guide, T.Anderson and M.McKell, Version 1.2, IMS, May 2001.

2. Relationship to Other Specifications

2.1 IMS Specifications

Version 1.1 of the IMS Enterprise Specification is made up of three documents:

The IMS Enterprise 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:

2.2 Related Specifications

2.2.1 IEEE P1484

The IEEE Learning Technology Standardization Committee P1484 is the only body engaged in the educational domain, which has a recognized 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, 988]. The IMS LIP has, in part, been derived from the PAPI (versions 5.0, 6.0 and 7.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 IMS Enterprise is focussed on the exchange of data within and between institutional Enterprise systems

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.

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 Enterprise Person structure.

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.

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 10 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 standardization 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.

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 Content Object Reference Model (SCORM v1.2) as a working document to encourage discussion and input on the emerging standards. No separate Enterprise specification work 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 organization from the IEEE LTSC.

2.3.4 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:

2.4 IMS Specification Development Process

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

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 website. 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 Core Data Objects

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

The principal exchangeable Enterprise data objects

Figure 3.1 The principal exchangeable Enterprise data objects.

The core objects are:

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 Transaction 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).

The simple data exchange mechanism

Figure 3.2 The simple data exchange mechanism.

3.3 XML Schema

Figures 3.3, 3.4, 3.5 and 3.6 show schematic representations of the XML binding of the Enterprise Information Model.

3.3.1 Enterprise Root Structure

The <person> element XML schema tree

Figure 3.3 The <person> element XML schema tree.
3.3.2. Person Data Object

The <person> element XML schema tree

Figure 3.4 The <person> element XML schema tree.
3.3.3. Group Data Object

The <group> element XML schema tree

Figure 3.5 The <group> element XML schema tree.

3.3.2 Membership Data Object

The <membership> element XML schema tree

Figure 3.6 The <membership> element XML schema tree.

4. Basic Example XML Instances

4.1 Person Examples

4.1.1 Create a Single Person Record

In this example a new Person record is created as shown by lines 005 (the message header control field) and 008 (the record transaction type).


<enterprise>
  <properties>
    <datasource>Dunelm Services Limited</datasource>
    <target>Telecommunications LMS</target>
    <type>CREATE</type>
    <datetime>2001-08-08</datetime>
  </properties>
  <person recstatus = "1">
    <comments>This an imaginary set of personal details.</comments>
    <sourcedid>
      <source>Dunelm Services Limited</source>
      <id>CS1</id>
    </sourcedid>
    <userid password = "myencryptedpassword" pwencryptiontype = "PKC" 
      authenticationtype = "Kerberos">ColinS34
    </userid>
    <name>
      <fn>Colin Smythe</fn>
      <sort>Smythe, C</sort>
      <nickname>Colin</nickname>
      <n>
        <family>Smythe</family>
        <given>Colin</given>
        <other>Manfred</other>
        <other>Wingarde</other>
        <prefix>Dr.</prefix>
        <suffix>C.Eng</suffix>
        <partname partnametype = "Initials">C.M.W.</partname>
      </n>
    </name>
    <demographics>
      <gender>2</gender>
      <bday>1958-02-18</bday>
      <disability>None.</disability>
    </demographics>
    <email>colin@dunelm.com</email>
    <url>http://www.dunelm.com</url>
    <tel teltype = "1">441142335019</tel>
    <tel teltype = "2">441142335019</tel>
    <adr>
      <pobox>PO Box 24</pobox>
      <extadd>Dunelm Services Limited</extadd>
      <street>34 Acorn Drive</street>
      <street>Stannington</street>
      <locality>Sheffield</locality>
      <region>S.Yorks</region>
      <pcode>S7 6WA</pcode>
      <country>UK</country>
    </adr>
    <photo imgtype = "gif">
      <extref>http://www.dunelm.com/staff/colin.gif</extref>
    </photo>
    <systemrole systemroletype = "User"/>
    <institutionrole primaryrole = "Yes" institutionroletype = "Faculty"/>
    <institutionrole primaryrole = "No" institutionroletype = "Student"/>
    <datasource>dunelm:colinsmythe:1</datasource>
  </person>
</enterprise>

Note: The usage of the new elements and attributes is denoted by the blue lines.

4.1.2 Create Multiple Person Records

In this example three Person records are to be processed: the first is a new record (line 008), the second is an update (line 028) and the third is a record deletion (line 071).


<enterprise>
  <properties>
    <datasource>Dunelm Services Limited</datasource>
    <target>Telecommunications LMS</target>
    <type>DATABASE UPDATE</type>
    <datetime>2001-08-08</datetime>
  </properties>
  <person recstatus = "1">
    <comments>Add a new Person record.</comments>
    <sourcedid>
      <source>Dunelm Services Limited</source>
      <id>CK1</id>
    </sourcedid>
    <name>
      <fn>Clark Kent</fn>
      <sort>Kent, C</sort>
      <nickname>Superman</nickname>
    </name>
    <demographics>
      <gender>2</gender>
    </demographics>
    <adr>
      <extadd>The Daily Planet</extadd>
      <locality>Metropolis</locality>
      <country>USA</country>
    </adr>
  </person>
  <person recstatus = "2">
    <comments>Update a previously created record.</comments>
    <sourcedid>
      <source>Dunelm Services Limited</source>
      <id>CS1</id>
    </sourcedid>
    <name>
      <fn>Colin Smythe</fn>
      <sort>Smythe, C</sort>
      <nickname>Colin</nickname>
      <n>
        <family>Smythe</family>
        <given>Colin</given>
        <other>Manfred</other>
        <other>Wingarde</other>
        <prefix>Dr.</prefix>
        <suffix>C.Eng</suffix>
        <partname partnametype = "Initials">C.M.W.</partname>
      </n>
    </name>
    <demographics>
      <gender>2</gender>
      <bday>1958-02-18</bday>
      <disability>None.</disability>
    </demographics>
    <email>colin@dunelm.com</email>
    <url>http://www.dunelm.com</url>
    <tel teltype = "Mobile">4477932335019</tel>
    <adr>
      <extadd>Dunelm Services Limited</extadd>
      <street>34 Acorn Drive</street>
      <street>Stannington</street>
      <locality> Sheffield</locality>
      <region>S.Yorks</region>
      <pcode>S7 6WA</pcode>
      <country>UK</country>
    </adr>
    <photo imgtype = "gif">
      <extref>http://www.dunelm.com/staff/colin2.gif</extref>
    </photo>
    <institutionrole primaryrole = "No" institutionroletype = "Alumni"/>
    <datasource>dunelm:colinsmythe:1</datasource>
  </person>
  <person recstatus = "3">
    <comments>Delete this record.</comments>
    <sourcedid>
      <source>Dunelm Services Limited</source>
      <id>LL1</id>
    </sourcedid>
    <name>
      <fn>Lois Lane</fn>
      <sort>Lane, L</sort>
    </name>
  </person>
</enterprise>

The salient points are:

4.2 Group Examples

4.2.1 Create a Single Group Record

In this example a new Group record is created as shown by lines 005 (the message header control field) and 008 (the record transaction type).


<enterprise>
  <properties>
    <datasource>University of Durham: SIS</datasource>
    <target>University of Durham: LMS</target>
    <type>CREATE</type>
    <datetime>2001-08-08</datetime>
  </properties>
  <group recstatus = "1">
    <comments>A comment about the Group.</comments>
    <sourcedid>
      <source>University of Durham: SIS</source>
      <id>1976_APE</id>
    </sourcedid>
    <grouptype>
      <scheme>University of Durham</scheme>
      <typevalue level = "2"/>
    </grouptype>
    <description>
      <short>Applied Physics 1976 Cohort</short>
    </description>
    <org>
      <orgname>University of Durham</orgname>
      <orgunit>Applied Physics</orgunit>
      <type>Academic Unit</type>
      <id>Electronics_101</id>
    </org>
    <timeframe>
      <begin restrict = "1">1976:10:01</begin>
      <end restrict = "1">1979:07:01</end>
      <adminperiod>Three year degree cohort:Oct, 1976 to July 1979.</adminperiod>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>0</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <email>cohort76@appliedphysics.dur.ac.uk</email>
    <url>http://www.dur.ac.uk/appiedphysics</url>
    <datasource>University of Durham: SIS</datasource>
  </group>
</enterprise>

4.2.2 Create Multiple Group Records

In this example two new Group records are created as shown by lines 005 (the message header control field) and 008 and 040 (the record transaction types).


<enterprise>
  <properties>
    <datasource>University of Durham: SIS</datasource>
    <target>University of Durham: LMS</target>
    <type>CREATE</type>
    <datetime>2001-08-08</datetime>
  </properties>
  <group recstatus = "1">
    <sourcedid>
      <source>University of Durham</source>
      <id>CS1</id>
    </sourcedid>
    <grouptype>
      <scheme>University of Durham</scheme>
      <typevalue level = "2"/>
    </grouptype>
    <description>
      <short>Applied Physics 1976 Cohort</short>
    </description>
    <org>
      <orgname>University of Durham</orgname>
      <orgunit>Applied Physics</orgunit>
      <type>Academic Unit</type>
      <id>Electronics_101</id>
    </org>
    <timeframe>
      <begin restrict = "1">1976:10:01</begin>
      <end restrict = "1">1979:07:01</end>
      <adminperiod>Three year degree cohort of: Oct, 1976 to July 1979.
      </adminperiod>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>0</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <email>cohort76@appliedphysics.dur.ac.uk</email>
    <url>http://www.dur.ac.uk/appiedphysics</url>
    <datasource>University of Durham: SIS</datasource>
  </group>
  <group recstatus = "1">
    <sourcedid>
      <source>University of Durham</source>
      <id>CS1.1</id>
    </sourcedid>
    <grouptype>
      <scheme>University of Durham</scheme>
      <typevalue level = "3"/>
    </grouptype>
    <description>
      <short>Applied Physics 1976 Cohort Maths Group</short>
    </description>
    <org>
      <orgname>University of Durham</orgname>
      <orgunit>Applied Physics</orgunit>
      <type>Academic Unit</type>
      <id>Applied_Physics_Maths_1</id>
    </org>
    <timeframe>
      <begin restrict = "1">1976:10:01</begin>
      <end restrict = "1">1977:07:01</end>
      <adminperiod>Maths Year 1 Lecture Group for Applied Physics 1976 Cohort
      </adminperiod>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>0</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <email>cohort76@appliedphysics.dur.ac.uk</email>
    <url>http://www.dur.ac.uk/appiedphysics</url>
    <relationship relation = "2">
      <sourcedid>
        <source>University of Durham</source>
        <id>CS1</id>
      </sourcedid>
      <label>Course Lecture Group</label>
    </relationship>
    <datasource>University of Durham: SIS</datasource>
  </group>
</enterprise>

4.2.3 Create Sub-Group Records

In this example the first Group is created (lines 008-028) and then a Sub-group is created (lines 029-045). This Sub-group is a child of the first Group created. The final transaction issues an update to the parent Group (lines 046-052). This explicit bi-directional binding of the relationship may not be necessary in some Enterprise systems.


<enterprise>
  <properties>
    <datasource>MLE</datasource>
    <target>VLE</target>
    <type>CREATE</type>
    <datetime>2002-03-31</datetime>
  </properties>
  <group recstatus = "1">
    <comments>A comment about the Parent Group.</comments>
    <sourcedid>
      <source>MLE</source>
      <id>Degree Cohort</id>
    </sourcedid>
    <grouptype>
      <scheme>University</scheme>
      <typevalue level = "1">Level 1 - Degree</typevalue>
    </grouptype>
    <description>
      <short>Three year degree cohort</short>
    </description>
    <org>
      <orgname>MIT</orgname>
      <orgunit>Physics</orgunit>
      <type>Academic Unit</type>
      <id>Physics_2002</id>
    </org>
    <datasource>MIT: SIS</datasource>
  </group>
  <group recstatus = "1">
    <comments>A comment about the Child Group. </comments>
    <sourcedid>
      <source>MLE</source>
      <id>Degree Cohort</id>
    </sourcedid>
    <description>
      <short>Three year degree cohort.</short>
    </description>
    <relationship relation = "2">
      <sourcedid>
        <source>MLE</source>
        <id>Year 1 Cohort</id>
      </sourcedid>
      <label>The Year 1 Cohort is the CHILD of the Degree Cohort.</label>
    </relationship>
  </group>
  <group recstatus = "2">
    <comments>A comment about the Parent Group</comments>
    <sourcedid>
      <source>MLE</source>
      <id>Year 1 Cohort</id>
    </sourcedid>
    <description>
      <short>First year cohort of the degree cohort.</short>
    </description>
    <relationship relation = "1">
      <sourcedid>
        <source>MLE</source>
        <id>Degree Cohort</id>
      </sourcedid>
      <label>The Degree Cohort is a PARENT of the Year 1 Cohort.</label>
    </relationship>
  </group>
</enterprise>

4.2.4 Support for Cross-Listed Groups

This example illustrates how the IMS Enterprise spec can be used to communicate information about cross-listed courses from a Student Information System (SIS) to a Learning Management System (LMS). Cross-listed courses are those that are listed as separate sections in course catalogue but are taught by the same instructor in the same room as one class. It means that what is listed, as multiple courses in SIS, should be presented to users as a single course in LMS.

Courses A, B, and C are listed as separate unrelated courses (sections), however, they are taught as one course (section) in LMS. LMS will associate students, TA (teaching assistant), and instructors with "Master" course. For course management and presentation purposes LMS may keep the following information:

The 'cross-listed' relation between courses is expressed using the <relationship> element in the group object with the "relation" attribute equal to 3 (also known as). If all three courses refer to each other, the order they appear in XML is not important. The first cross-listed course encountered by LMS is setup as the "Master" course.

Cross-listed courses structure example

Figure 4.1 Cross-listed courses structure example.

<enterprise>
  <properties>
    <datasource>BANNER University SCT banner</datasource>
    <type>Initial creation</type>
    <datetime>2002-10-18t10:22:36</datetime>
  </properties>
  <group>
    <!--course section data object-->
    <sourcedid>
      <source>BANNER University SCT banner</source>
      <id>10001.200210</id>
    </sourcedid>
    <grouptype>
      <typevalue level = "1">Instruction</typevalue>
      <typevalue level = "2">Term</typevalue>
      <typevalue level = "3">Course</typevalue>
      <typevalue level = "4">Section</typevalue>
    </grouptype>
    <description>
      <short>chem-1151-001</short>
      <long>General Chemistry I</long>
    </description>
    <org>
      <orgname>BANNER University</orgname>
      <orgunit>Chemistry</orgunit>
      <id>123456</id>
    </org>
    <timeframe>
      <begin>2002-09-05</begin>
      <end>2002-12-19</end>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>1</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10002.200210</id>
      </sourcedid>
      <label>Cross-listed course</label>
    </relationship>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10003.200210</id>
      </sourcedid>
      <label>Cross-listed course</label>
    </relationship>
    <datasource>BANNER University SCT banner</datasource>
  </group>
  <group>
    <!--course section data object-->
    <sourcedid>
      <source>BANNER University SCT banner</source>
      <id>10002.200210</id>
    </sourcedid>
    <grouptype>
      <typevalue level = "1">instruction</typevalue>
      <typevalue level = "2">term</typevalue>
      <typevalue level = "3">course</typevalue>
      <typevalue level = "4">section</typevalue>
    </grouptype>
    <description>
      <short>chem-1151-101</short>
      <long>Chemistry Introduction</long>
    </description>
    <org>
      <orgname>BANNER university</orgname>
      <orgunit>Chemistry</orgunit>
      <id>123456</id>
    </org>
    <timeframe>
      <begin>2002-09-05</begin>
      <end>2002-12-19</end>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>1</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10001.200210</id>
      </sourcedid>
      <label>cross-listed course</label>
    </relationship>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10003.200210</id>
      </sourcedid>
      <label>cross-listed course</label>
    </relationship>
    <datasource>BANNER University SCT banner</datasource>
  </group>
  <group>
    <!--course section data object-->
    <sourcedid>
      <source>BANNER University SCT banner</source>
      <id>10003.200210</id>
    </sourcedid>
    <grouptype>
      <typevalue level = "1">Instruction</typevalue>
      <typevalue level = "2">Term</typevalue>
      <typevalue level = "3">Course</typevalue>
      <typevalue level = "4">Section</typevalue>
    </grouptype>
    <description>
      <short>eng-1151-156</short>
      <long>General Chemistry</long>
    </description>
    <org>
      <orgname>BANNER university</orgname>
      <orgunit>Engineering</orgunit>
      <id>123456</id>
    </org>
    <timeframe>
      <begin>2002-09-05</begin>
      <end>2002-12-19</end>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>1</enrollaccept>
      <enrollallowed>0</enrollallowed>
    </enrollcontrol>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10002.200210</id>
      </sourcedid>
      <label>cross-listed course</label>
    </relationship>
    <relationship relation = "3">
      <sourcedid>
        <source>BANNER University SCT banner</source>
        <id>10001.200210</id>
      </sourcedid>
      <label>cross-listed course</label>
    </relationship>
    <datasource>BANNER University SCT banner</datasource>
  </group>
</enterprise>

4.3 Membership Examples

4.3.1 Create a Single Membership Record

This example illustrates the creation of two Member records (lines 013-046 and 047-080) in the Group identified (lines 009-012). A role is defined in the first Member record (lines 019-045).


<enterprise>
  <properties>
    <datasource>University of Durham: LMS</datasource>
    <target>University of Durham: SIS</target>
    <type>CREATE</type>
    <datetime>2002-03-31</datetime>
  </properties>
  <membership>
    <sourcedid>
      <source>University of Durham: SIS</source>
      <id>2000_APE</id>
    </sourcedid>
    <member>
      <sourcedid>
        <source>University of Durham: SIS</source>
        <id>2000_APE_001</id>
      </sourcedid>
      <idtype>1</idtype>
      <role>
        <status>1</status>
        <datetime>2001-10-01</datetime>
        <timeframe>
          <begin restrict = "0">2000-10-01</begin>
          <end restrict = "0">2001-07-01</end>
          <adminperiod>2000-01 Academic Year</adminperiod>
        </timeframe>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>65</result>
          <comments>Examination Result: Passed</comments>
        </finalresult>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>60</result>
          <comments>Practical Result: Passed</comments>
        </finalresult>
      </role>
    </member>
    <member>
      <sourcedid>
        <source>University of Durham: SIS</source>
        <id>2000_APE_004</id>
      </sourcedid>
      <idtype>1</idtype>
      <role>
        <status>1</status>
        <datetime>2001-10-01</datetime>
        <timeframe>
          <begin restrict = "0">2000-10-01</begin>
          <end restrict = "0">2001-07-01</end>
          <adminperiod>2000-01 Academic Year</adminperiod>
        </timeframe>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>60</result>
          <comments>Examination Result: Passed</comments>
        </finalresult>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>30</result>
          <comments>Practical Result: Failed</comments>
        </finalresult>
      </role>
    </member>
  </membership>
</enterprise>

4.3.2 Create Multiple Membership Records

In this example two Membership instances are created. Each Membership contains a single Member each with one role being defined.


<enterprise>
  <properties>
    <datasource>University of Durham: LMS</datasource>
    <target>University of Durham: SIS</target>
    <type>CREATE</type>
    <datetime>2002-03-31</datetime>
  </properties>
  <membership>
    <sourcedid>
      <source>University of Durham: SIS</source>
      <id>2000_APE</id>
    </sourcedid>
    <member>
      <sourcedid>
        <source>University of Durham: SIS</source>
        <id>2000_APE_004</id>
      </sourcedid>
      <idtype>1</idtype>
      <role>
        <status>1</status>
        <datetime>2001-10-01</datetime>
        <timeframe>
          <begin restrict = "0">2000-10-01</begin>
          <end restrict = "0">2001-07-01</end>
          <adminperiod>2000-01 Academic Year</adminperiod>
        </timeframe>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>60</result>
          <comments>Examination Result: Passed</comments>
        </finalresult>
        <finalresult>
          <mode>Percentage</mode>
          <values valuetype = "1">
            <min>0</min>
            <max>100</max>
          </values>
          <result>30</result>
          <comments>Practical Result: Failed</comments>
        </finalresult>
      </role>
    </member>
  </membership>
  <membership>
    <sourcedid>
      <source>University of Durham: HR</source>
      <id>Staff_3</id>
    </sourcedid>
    <member>
      <sourcedid>
        <source>University of Durham: HR</source>
        <id>Staff:625745</id>
      </sourcedid>
      <idtype>1</idtype>
      <role roletype = "01">
        <status>1</status>
        <datetime>2001-10-01</datetime>
        <timeframe>
          <begin restrict = "0">1980-10-01</begin>
          <end restrict = "0">2021-07-01</end>
          <adminperiod>Employment until Retirement</adminperiod>
        </timeframe>
      </role>
    </member>
  </membership>
</enterprise>

5. Advanced Example XML Instances

5.1 A V1.0 Example Renovated in V1.1 Format

Below is an example, from Blackboard, that includes Person, Group and Membership structures based upon the V1.0 Enterprise Specification. It includes uses of Blackboard extensions (see the shaded lines).


<ENTERPRISE>
  <PROPERTIES>
    <DATASOURCE>California State University San Marcos</DATASOURCE>
    <TARGET>Computing and Telecommunications LMS</TARGET>
    <TYPE>REFRESH</TYPE>
    <DATETIME>1999-02-03</DATETIME>
  </PROPERTIES>
  <PERSON transaction="2">
    <SOURCEDID>
      <SOURCE>California State University San Marcos</SOURCE>
      <ID>111-22-3344<!--Campus User Key -->
      </ID>
    </SOURCEDID>
    <USERID>rpeterson<!--Username-->
    </USERID>
    <NAME>
      <FN>Raymond F. Peterson</FN>
      <SORT>Peterson, Raymond</SORT>
      <NICKNAME>Ray</NICKNAME>
      <N>
        <FAMILY>Peterson<!--Last Name-->
        </FAMILY>
        <GIVEN>Raymond<!--First Name-->
        </GIVEN>
        <OTHER>Franklin<!--Middle Name-->
        </OTHER>
        <PREFIX>Mr.<!--Title-->
        </PREFIX>
      </N>
    </NAME>
    <DEMOGRAPHICS>
      <BDAY>1972-10-11<!--Birthday-->
      </BDAY>
    </DEMOGRAPHICS>
    <EMAIL>rpeterson@blackboard.com<!--User Email-->
    </EMAIL>
    <TEL teltype="1">7607504785
    </TEL>
    <TEL teltype="2">7607503257</TEL>
    <ADR>
      <STREET>1899 L Street<!--Address Line 1-->
      </STREET>
      <STREET>234243<!--Address Line 2-->
      </STREET>
      <LOCALITY>Washington<!--City-->
      </LOCALITY>
      <REGION>DC<!--State Province-->
      </REGION>
      <PCODE>20036<!--Zip postal code-->
      </PCODE>
      <COUNTRY>US<!--Country-->
      </COUNTRY>
    </ADR>
    <EXTENSION>
      <X_BB_SYSTEMROLE>0<!--0-System Admin -->
      </X_BB_SYSTEMROLE>
      <X_BB_INSTITUTIONROLE>0<!-- 0-Student -->
      </X_BB_INSTITUTIONROLE>
      <X_BB_STUDENTID>144532<!--Person Id-->
      </X_BB_STUDENTID>
      <X_BB_PASSWORD>rpeterson<!--User Password-->
      </X_BB_PASSWORD>
    </EXTENSION>
  </PERSON>
  <PERSON transaction="1">
    <SOURCEDID>
      <SOURCE>California State University San Marcos</SOURCE>
      <ID>111-22-3344<!--Campus User Key-->
      </ID>
    </SOURCEDID>
    <USERID>rpeterson<!--Username-->
    </USERID>
    <NAME>
      <FN>Raymond F. Peterson</FN>
      <SORT>Peterson, Raymond</SORT>
      <NICKNAME>Ray</NICKNAME>
      <N>
        <FAMILY>Peterson<!--Last Name-->
        </FAMILY>
        <GIVEN>Raymond<!--First Name-->
        </GIVEN>
        <OTHER>Franklin<!--Middle Name-->
        </OTHER>
        <PREFIX>Mr.<!--Title-->
        </PREFIX>
      </N>
    </NAME>
    <DEMOGRAPHICS>
      <BDAY>1972-10-11<!--Birthday-->
      </BDAY>
    </DEMOGRAPHICS>
    <EMAIL>rpeterson@blackboard.com<!--User Email-->
    </EMAIL>
    <TEL teltype="1">7607504785<!--Telphone. 1-Home Fax -->
    </TEL>
    <TEL teltype="2">7607503257</TEL>
    <ADR>
      <STREET>1899 L Street<!--Address Line 1-->
      </STREET>
      <STREET>234243<!--Address Line 2-->
      </STREET>
      <LOCALITY>Washingtom<!--City-->
      </LOCALITY>
      <REGION>DC<!--State Province-->
      </REGION>
      <PCODE>20036<!--Zip postal code-->
      </PCODE>
      <COUNTRY>US<!--Country-->
      </COUNTRY>
    </ADR>
    <EXTENSION>
      <X_BB_SYSTEMROLE>0<!-- 0-System Admin -->
      </X_BB_SYSTEMROLE>
      <X_BB_INSTITUTIONROLE>1<!-- 1-Faculty -->
      </X_BB_INSTITUTIONROLE>
      <X_BB_STUDENTID>144123<!--Person Id-->
      </X_BB_STUDENTID>
      <X_BB_PASSWORD>wlove<!--User Password-->
      </X_BB_PASSWORD>
    </EXTENSION>
  </PERSON>
  <GROUP transaction="1">
    <SOURCEDID>
      <SOURCE>College of Arts and Sciences</SOURCE>
      <ID>CS-697C-Section_1_Fall_1999<!--Course Section Key-->
      </ID>
    </SOURCEDID>
    <GROUPTYPE>
      <SCHEME>Blackboard, Inc.</SCHEME>
      <!--Only scheme currently supported. Anything else is in error.-->
      <TYPEVALUE level="0">1<!--Service Level. 0-Course, 1-Organization-->
      </TYPEVALUE>
    </GROUPTYPE>
    <DESCRIPTION>
      <SHORT>Security-In-Computing<!--Abbreviated Title-->
      </SHORT>
      <LONG>Graduate Level Special Topics course security in computing today.
      </LONG>
      <FULL>This course will examine threats and security issues in today's common 
        computing environments. Prerequisites: Advanced Networks (CS 301) and 
        Cryptography (CS 633).<!--Course Description-->
      </FULL>
    </DESCRIPTION>
    <ORG>
      <ORGNAM>College of Arts and Sciences</ORGNAM>
      <ORGUNIT>Computer Science</ORGUNIT>
      <TYPE>Academic</TYPE>
    </ORG>
    <TIMEFRAME>
      <BEGIN restrict="0">1999-08-26<!--Start Date-->
      </BEGIN>
      <END restrict="0">1999-12-20<!--End Date-->
      </END>
      <ADMINPERIOD>Fall 1999</ADMINPERIOD>
    </TIMEFRAME>
    <ENROLLCONTROL>
      <ENROLLACCEPT>1</ENROLLACCEPT>
    </ENROLLCONTROL>
    <EXTENSION>
      <X_BB_GROUP_TYPE>1<!--Service Level. 0-Course, 1-Organization-->
      </X_BB_GROUP_TYPE>
    </EXTENSION>
  </GROUP>
  <MEMBERSHIP>
    <SOURCEDID>
      <SOURCE>College of Arts and Sciences</SOURCE>
      <ID>CS-697C-Section_1_Fall_1999<!--Course Section Key-->
      </ID>
    </SOURCEDID>
    <MEMBER>
      <SOURCEDID>
        <SOURCE>California State University San Marcos</SOURCE>
        <ID>111-22-3344<!--Campus user Key-->
        </ID>
      </SOURCEDID>
      <IDTYPE idtype="1"/>
      <ROLE transaction="1" roletype="01">
        <!--Course Role. 0-Instructor, 1-Teaching Assistant, 2-Course Builder, 
        3-Grader, 4-Student, 5-Guest, 6-None-->
        <STATUS>1</STATUS>
        <COMMENTS>This student has no special needs.</COMMENTS>
        <FINALRESULT>
          <MODE>Letter Grade requested</MODE>
          <VALUES listrange="0">
            <LIST>A</LIST>
            <LIST>C</LIST>
            <LIST>F</LIST>
          </VALUES>
        </FINALRESULT>
      </ROLE>
    </MEMBER>
  </MEMBERSHIP>
</ENTERPRISE>

The equivalent v1.1 XML instance is shown below. The structures that have been used instead of the Blackboard extensions are shown in blue.


<enterprise>
  <properties>
    <datasource>California State University San Marcos</datasource>
    <target>Computing and Telecommunications LMS</target>
    <type>REFRESH</type>
    <datetime>1999-02-03</datetime>
  </properties>
  <person recstatus = "2">
    <sourcedid>
      <source>California State University San Marcos</source>
      <id>111-22-3344
        <!--campus user key -->
      </id>
    </sourcedid>
    <userid password = "rpeterson" useridtype = "username">rpeterson</userid>
    <userid useridtype = "StudentId">144532</userid>
    <name>
      <fn>Raymond F. Peterson</fn>
      <sort>Peterson, Raymond</sort>
      <nickname>Ray</nickname>
      <n>
        <family>Peterson
          <!--last name-->
        </family>
        <given>Raymond
          <!--first name-->
        </given>
        <prefix>Mr.
          <!--title-->
        </prefix>
        <partname partnametype = "Middle">Franklin</partname>
      </n>
    </name>
    <demographics>
      <bday>1972-10-11
        <!--birthday-->
      </bday>
    </demographics>
    <email>rpeterson@blackboard.com
      <!--user email-->
    </email>
    <tel teltype = "1">7607504785
      <!--telphone. 0-home phone 1, 1-home fax, 2-workphone 1, 3-work fax, 4-
      mobile phone-->
    </tel>
    <tel teltype = "2">7607503257</tel>
    <adr>
      <street>1899 L Street
        <!--address line 1-->
      </street>
      <street>234243
        <!--address line 2-->
      </street>
      <locality>Washington
        <!--city-->
      </locality>
      <region>DC
        <!--state province-->
      </region>
      <pcode>20036
        <!--zip postal code-->
      </pcode>
      <country>US
        <!--country-->
      </country>
    </adr>
    <systemrole systemroletype = "SysAdmin"/>
    <institutionrole primaryrole = "Yes" institutionroletype = "Student"/>
  </person>
  <person recstatus = "1">
    <sourcedid>
      <source>California State University San Marcos</source>
      <id>111-22-3344
        <!--campus user key-->
      </id>
    </sourcedid>
    <userid password = "wlove" useridtype = "username">rpeterson</userid>
    <userid useridtype = "StudentId">144123</userid>
    <name>
      <fn>Raymond F. Peterson</fn>
      <sort>Peterson, Raymond</sort>
      <nickname>Ray</nickname>
      <n>
        <family>Peterson
          <!--last name-->
        </family>
        <given>Raymond
          <!--first name-->
        </given>
        <other>Franklin
          <!--middle name-->
        </other>
        <prefix>Mr.
          <!--title-->
        </prefix>
      </n>
    </name>
    <demographics>
      <bday>1972-10-11
        <!--birthday-->
      </bday>
    </demographics>
    <email>rpeterson@blackboard.com
      <!--user email-->
    </email>
    <tel teltype = "1">7607504785
      <!--telphone. 0-home phone 1, 1-home fax, 2-workphone 1, 3-work fax, 4-
      mobile phone-->
    </tel>
    <tel teltype = "2">7607503257</tel>
    <adr>
      <street>1899 L Street
        <!--address line 1-->
      </street>
      <street>234243
        <!--address line 2-->
      </street>
      <locality>Washingtom
        <!--city-->
      </locality>
      <region>DC
        <!--state province-->
      </region>
      <pcode>20036
        <!--zip postal code-->
      </pcode>
      <country>US
        <!--country-->
      </country>
    </adr>
    <systemrole systemroletype = "SysAdmin"/>
    <institutionrole primaryrole = "Yes" institutionroletype = "Faculty"/>
  </person>
  <group recstatus = "1">
    <sourcedid>
      <source>College of Arts and Sciences</source>
      <id>CS-697C-Section_1_Fall_1999
        <!--course section key-->
      </id>
    </sourcedid>
    <grouptype>
      <scheme>Blackboard, Inc.</scheme>
      <!--Only scheme currently supported. Anything else is in error.-->
      <typevalue level = "0">1
        <!--Service level. 0-Course, 1-Organization-->
      </typevalue>
    </grouptype>
    <description>
      <short>Security-In-Computing</short>
      <long>Graduate Level Special Topics course covering security in computing 
        today.<!--title-->
      </long>
      <full>This course will examine threats and security issues in today's common 
        computing environments. Prerequisites: Advanced Networks (CS 301) and 
        Cryptography (cs 633).<!--course description-->
      </full>
    </description>
    <org>
      <orgname>College of Arts and Sciences</orgname>
      <orgunit>Computer Science</orgunit>
      <type>Academic</type>
    </org>
    <timeframe>
      <begin restrict = "0">1999-08-26
        <!--start date-->
      </begin>
      <end restrict = "0">1999-12-20
        <!--end date-->
      </end>
      <adminperiod>Fall 1999</adminperiod>
    </timeframe>
    <enrollcontrol>
      <enrollaccept>1</enrollaccept>
    </enrollcontrol>
  </group>
  <membership>
    <sourcedid>
      <source>College of Arts and Sciences</source>
      <id>CS-697C-Section_1_Fall_1999
        <!--course section key-->
      </id>
    </sourcedid>
    <member>
      <sourcedid>
        <source>California State University San Marcos</source>
        <id>111-22-3344
          <!--campus user key-->
        </id>
      </sourcedid>
      <idtype>1</idtype>
      <role recstatus = "1" roletype = "01">
        <!--course role. 0-instructor, 1-teaching assistant, 2-course builder, 
        3-grader, 4-student, 5-guest, 6-none-->
        <status>1</status>
        <comments>This student has no special needs.</comments>
        <finalresult>
          <mode>Letter Grade requested</mode>
          <values valuetype = "0">
            <list>A</list>
            <list>C</list>
            <list>F</list>
          </values>
        </finalresult>
      </role>
    </member>
  </membership>
</enterprise>

5.2 A Course Catalog

An example of the usage of the Group structure to support the definition of a course catalogue is shown below. This makes use of the <group_members> element to contain the associated courses (lines 034-131).


<enterprise>
  <properties>
    <datasource>QLS</datasource> 
    <target>MLE</target> 
    <type>Query</type> 
    <datetime>2001-10-25</datetime> 
  </properties>
  <person>
    <sourcedid>
      <source>QLS</source>
      <id>p654321</id>
    </sourcedid>
    <name>
      <fn>Some Body</fn>
    </name>
    <tel>+44 1162 123456</tel>
  </person>
  <group>
    <sourcedid>
      <source>QLS</source> 
      <id>cc205</id> 
    </sourcedid>
    <grouptype>
      <scheme/> 
      <typevalue level = "p"/> 
    </grouptype>
    <description>
      <short>computing (p/t)</short> 
    </description>
    <timeframe>
      <begin restrict = "0">9/21/98</begin> 
      <end restrict = "0">9/30/01</end> 
    </timeframe>
    <groupmembers>
      <sourcedid>
        <source>QLS</source>
        <id>soft 1234</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 2345</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 3456</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 4567</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 5678</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 6789</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 4321</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 5432</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 6543</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 7654</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 8765</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 9876</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 0987</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 1111</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 2222</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 3333</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 4444</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 5555</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 6666</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 7777</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 8888</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 9999</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 0000</id>
      </sourcedid>
      <sourcedid>
        <source>QLS</source>
        <id>soft 1357</id>
      </sourcedid>
    </groupmembers>
  </group>
  <membership>
    <sourcedid>
      <source>QLS</source> 
      <id>cc205</id> 
    </sourcedid>
    <member>
      <sourcedid>
        <source>QLS</source> 
        <id>p654321</id> 
      </sourcedid>
      <idtype>1</idtype> 
      <role roletype = "01">
        <status>1</status> 
      </role>
    </member>
  </membership>
</enterprise>

6. IMS Enterprise and Other Specifications

6.1 IMS Specifications

6.1.1 IMS Learner Information Package (LIP) Mapping

The mapping between the IMS Enterprise <person> element and the IMS LIP <identification> element is shown in Table 6.1.

Table 6.1 Mapping between IMS Enterprise <person> and IMS LIP <identification>.

Original <person> sub-elements
Equivalent <identification> sub-elements
<person><recstatus>Entry
<ext_contentype>
  <keyfields>
    <fieldlabel>
      <typename>
        <tyvalue>Recstatus
    <fielddata>Entry
<sourcedid>
<source>Entry1
<id>Entry2
<contentype>
  <referential>
    <sourcedid>
      <source>Entry1
      <id>Entry2
<userid>Entry
<demographics><uid>Entry
<name><fn>Entry
<formname>
  <typename>
    <tyvalue>Full
  <text>Entry
<name><sort>Entry
<formname>
  <typename>
    <tyvalue>Sort
  <text>Entry
<name><nickname> Entry
<name>
  <partname>
    <typename>
      <tyvalue>Nickname
    <text>Entry
<name><n><family>Entry
<name>
  <partname>
    <typename>
      <tyvalue>Family
    <text>Entry
<name><n><given>Entry
<name>
  <partname>
    <typename>
      <tyvalue>Given
    <text>Entry
<name><n><other>Entry
<name>
  <partname>
    <typename>
      <tyvalue>Other
    <text>Entry
<name><n><prefix>Entry
<name>
  <partname>
    <typename>
      <tyvalue>Prefix
    <text>Entry
<name><n><suffix>Entry
<name>
  <partname>
    <typename>
      <tyvalue>Suffix
    <text>Entry
<name><n>
<partname partnametype=Entry1>Entry2
<name>
  <partname>
    <typename>
      <tyvalue> Entry1
    <text>Entry
<demographics><gender>1


<demographics><gender>2
<demographics>
  <gender gender="M"/>

<demographics>
  <gender gender="F"/>
<demographics><bday>Entry
<demographics>
  <date>
    <typename>
      <tyvalue>DoB
    <datetime>Entry
<demographics><disability>Entry
<ext_identification>Entry
<email>Entry
<contactinfo>
  <email>Entry
<url>Entry
<contactinfo>
  <web>Entry
<tel teltype=1>Entry
<contactinfo>
  <telephone>
    <areacode>Entry
    <indnumber>Entry
<tel teltype=2>Entry
<contactinfo>
  <facsimile>
    <areacode>Entry
    <indnumber>Entry
<tel teltype=3>Entry
<contactinfo>
  <mobile>
    <areacode>Entry
    <indnumber>Entry
<tel teltype=4>Entry
<contactinfo>
  <pager>
    <areacode>Entry
    <indnumber>Entry
<adr><pobox>Entry
<contactinfo>
  <address>
    <pobox>Entry
<adr><extadd>Entry
<contactinfo>
  <address>
    <street>
      <nonfieldedstreetaddress>Entry
<adr><street>Entry
<contactinfo>
  <address>
    <street>
      <nonfieldedstreetaddress>Entry
<adr><locality>Entry
<contactinfo>
  <address>
    <locality>Entry
<adr><region>Entry
<contactinfo>
  <address>
    <region>Entry
<adr><pcode>Entry
<contactinfo>
  <address>
    <postcode>Entry
<adr><country>Entry
<contactinfo>
  <address>
    <country>Entry
<photo><extref>Entry
<demographics>
  <representation>
    <description>
      <full>
        <media>Entry
<system_role>Entry
<ext_identification>Entry
<institution_role>Entry
<ext_identification>Entry
<datasource>Entry
<contentype>
  <referential>
    <indexid>Entry
<extension>Entry
<ext_identification>Entry

6.2 Other Specifications

6.2.1 IETF vCard Mapping

The IMS Enterprise is compatible with the IETF vCard specification i.e. many of the vCard fields can be contained by an Enterprise-XML instance and the rest are supported through the use of the Person extension element. This relationship is shown in Table 6.2, namely:

Table 6.2 The usage of IMS Enterprise to support the IETF vCard specification.

vCard Element
IMS Enterprise Element(s)
Notes
FN
person.name.fn
The formatted name.
n
person.name.n
The name.
     family
person.name.n.family
Family name component.
     given
person.name.n.given
Given name component.
     other
person.name.n.other
Other name components.
     prefix
person.name.n.prefix
Prefix name component.
     suffix
person.name.n.suffix
Suffix name component.
nickname
person.name.nickname
Nickname.
photo
person.photo
A photograph of the Person.
bday
person.demographics.bday
The birth date of the Person.
addr
person.adr
The address.
     pobox
person.adr.pobox
The PO Box address component.
     extadd
person.adr.extadd
The extended address.
     street
person.adr.street
The street address component.
     locality
person.adr.locality
The locality address component.
     region
person.adr.region
The region address component.
     pcode
person.adr.pcode
The post code/zip code address component.
     country
person.adr.country
The country address component.
label
person.extension
Requires the usage of the Person extension feature.
tel
person.tel
The telephone number.
email
person.email
The email address.
mailer
person.extension
Requires the usage of the Person extension feature.
tz
person.extension
Requires the usage of the Person extension feature.
geo
person.extension
Requires the usage of the Person extension feature.
     lat
person.extension
Requires the usage of the Person extension feature.
     lon
person.extension
Requires the usage of the Person extension feature.
title
person.extension
Requires the usage of the Person extension feature.
role
person.extension
Requires the usage of the Person extension feature.
logo
person.extension
Requires the usage of the Person extension feature.
agent
person.extension
Requires the usage of the Person extension feature.
org
person.extension
Requires the usage of the Person extension feature.
categories
person.extension
Requires the usage of the Person extension feature.
     item
person.extension
Requires the usage of the Person extension feature.
note
person.extension
Requires the usage of the Person extension feature.
sort
person.name.sort
The sort form for the name.
sound
person.extension
Requires the usage of the Person extension feature.
url
person.url
The Web URL.
key
person.userid
Security keys.

6.2.2 Internet2/Educause 'eduPerson' Mapping

The eduPerson specification is an object class for LDAP services whereas Enterprise is a set of data objects for the exchange of learner Enterprise information and not just directory-related information. The relationship between the eduPerson V1.0 specification and the IMS Enterprise V1.1 is summarized in Table 6.3.

Table 6.3 The usage of IMS Enterprise to exchange the eduPerson information

EduPerson Object Definition
IMS Enterprise Person Data Structure
Comments
EduPersonAffiliation
(OID: 1.3.6.1.4.1.5923.1.1.1.1)
person.institution_role
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)
person.name.nickname
Person's nickname, or the informal name by which they are accustomed to be hailed.
EduPersonOrgDN
(OID: 1.3.6.1.4.1.5923.1.1.1.3)
person.extension
The distinguished name (DN) of the directory entry representing the institution with which the person is associated. The Person extension structure must be used.
EduPersonOrgUnitDN
(OID: 1.3.6.1.4.1.5923.1.1.1.4)
person.extension
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). The Person extension structure must be used.
EduPersonPrimaryAffiliation
(OID: 1.3.6.1.4.1.5923.1.1.1.5)
person.institution_role
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)
person.userid
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 contained within Person <userid> element.

6.2.3 LDAP Attribute Mapping

Most enterprise systems utilize a directory to store organizational and person information. Many directories use the Lightweight Directory Access Protocol (LDAP) to store this data and make it accessible to other Enterprise applications. It is likely that Learning Management Systems will use some of the data in an LDAP directory to populate equivalent fields in the IMS Enterprise XML Binding. Table 6.4 represents a preliminary mapping between LDAP base schema items and IMS Enterprise elements. This is provided only as an example. The reader who wishes to incorporate LDAP data into learning management applications is encouraged to consult authoritative sources regarding LDAP.

Table 6.4 The mapping of IMS Enterprise to LDAP attributes.

IMS Data Object
IMS Enterprise Data Structure
LDAP Attribute Name, Alias
Person
<sourcedid>
Uid
<name><nickname>
cn, commonName
<name><n><family>
sn, surName
<name><n><given>
GivenName
<tel>
TelephoneNumber
<adr>
PostalAddress
<adr><pobox>
PostOfficeBox
<adr><street>
Street
<adr><locality>
l, locality, localityname
<adr><country>
c, countryName
<photo>
Photo
Group
<sourcedid>
o, organization
<org><orgname>
o, organization
<org><orgunit>
ou, organizationUnitName
<org><type>
BusinessCategory
Membership
<member><role><userid>
Uid

7. Implementation Guidance

7.1 Achieving Interoperability

7.1.1 Interworking Enterprise Systems

The following list describes some types of systems for which the IMS Enterprise Specification may support Learning Management interoperability. It includes a list of some interfaces that the current specification can support.

7.1.1.1 Human Resource Management System

Human Resource Management Systems (HRMS) manage personnel records, payroll, benefits, competency management, and other functions for an enterprise. Interoperability that can be supported by this specification include:

From HRMS to LMS:

From LMS to HRMS:

7.1.1.2 Corporate Training Management System

Corporate Training Administration systems keep track of employee training plans, schedule training courses (including instructors and resources), enroll people in training, record training completed, and update employee competencies in an HRMS. They are also used to manage training delivered to customers. Interoperability that can be supported by this specification include:

From Training to LMS:

From LMS to Training:

7.1.1.3 Student Administration System

Student Administration systems (SA) keep track of student education plans, schedule courses (including instructors and resources), enroll people in courses, record course results, and update student academic progress. Interoperability that can be supported by this specification include:

From SA to LMS:

From LMS to SA:

7.1.1.4 Library Management System

Library Management systems can be thought of as a particular class of Learning Management system, in that they provide a set of services for managing the interaction of learners with learning objects. Therefore, it is appropriate to use this specification to support interfaces from other enterprise systems to Library Management systems in much the same way that these interfaces are supported with Learning Management Systems.

From SA or HRMS to Library:

7.2 Architectural Considerations

7.2.1 Interface Architectures

The IMS Enterprise Information Model and XML Binding Specification are intended to support either the "Snapshot" or Event Driven interface types discussed.

7.2.1.1 The "Snapshot" Interface

The IMS Enterprise team's consensus is that the most robust and easily implemented interface would involve the passing of a complete "snapshot" of the Person, Group, and Group Membership data. The target system would examine this snapshot to determine what changes had occurred. This very basic type of interface allows a receiving system to pick up an interface at any time and synchronize its data with the source system - regardless of how many interfaces had been passed in the interim. A purely event driven "transactional" interface, on the other hand, cannot tolerate any loss or skipping of interface records.

This basic interface also allows the target system to implement many different strategies for dealing with the interface data. Taking a "snapshot" means that the full set of relevant data from the source system can be moved to the target system environment on any timing needed to support the business processes. This interface architecture has the advantage of being very tolerant of lost messages or missed data objects because the next transmittal will always get the target system back in synchronization with the source system. However, the major drawback is that the target system can never be sure that the data has not changed in the source system since the last snapshot was received. Also, this interface architecture does not effectively support two-way interfaces. In a two-way interface, data object maintenance occurs in both systems, and the data objects are passed in both directions.

7.2.1.2 Event Driven Interface

In an event driven interface, the source system publishes data object messages when events occur. This changes the relevant data, and the target system receives and processes the event transactions. The existence of an event driven interface does not eliminate the usefulness of the "snapshot" interface. Because an event driven interface is not tolerant of missed transactions, the "snapshot" interface can be used at regular intervals to "re-synchronize" the data in the target system with that in the source system. This increases the fault tolerance of the overall interface architecture.

7.2.2 Single File from Multiple Systems

During integration engagements conducted by Blackboard in the Summer and Fall of 1999, it was determined that some institutions might store certain objects in multiple systems. The initial version of the IMS Enterprise Information Model V1.0 handled this situation if the file was sent separately from each system and the system was identified by the <datasource> attribute in Properties. However, Blackboard found that some institutions preferred to produce one file and send that to Blackboard CourseInfo Enterprise. In this case a <datasource> attribute at the file level is not sufficient. It was recommended that the IMS Enterprise Information Model be changed to include a <datasource> element for People, Groups and Group Membership. The element would be at the top level for People and Groups, but off Role for Group Membership. This <datasource> element identifies the system from which the record (object) came while the source in the sourcedid identifies the system that guarantees the uniqueness of the record. This modification was introduced in V1.01 and is sustained in V1.1.

7.2.3 Addresses and Identifiers

An underlying assumption in a transaction-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 simple object addressing scheme

Figure 7.1 The simple object addressing scheme.

The usage of the 'sourcedid' for labelling the objects being exchanged gives rise to the scenario shown in Figure 7.1. 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.

7.3 Using Person

Within the IMS Enterprise Specification the Person structure has undergone the most significant changes. The salient points to note when using the person structure are:

7.4 Using Group

7.4.1 Groups and Sub-Groups

The Group structure is used as a generic collection structure for objects that have a similar functionality, responsibility, etc. It can be a Group of other Groups or a Group of Person records. A Group does not contain Sub-groups per se but the relationship between one Group and another can be defined as per a sub-grouping.

The relationship between two Groups is defined using the <relationship> element. This allows the definition of uni-directional and bi-directional references depending on the desired implementation. The sub-group hierarchy is defined using the '1=Parent' and '2=Child' values in the <relation> attribute of the <relationship> element. This tree structure can be defined to have any number of roots and the equivalence of Groups can be defined using the '3-Cross Listing' value for <relation>.

7.4.2 Cross-Listed Course Sections

Cross-Listed course sections are a fairly common scenario in higher education. A Cross-Listed course section refers to a situation where the same course is offered under more than one name. This is typically done because different groups of students will enroll in different sections based on the program they are studying. For example, Statistics 101 section 1 and Psychology 101 section 1 are really the same course section, offered by the same instructor, meeting at the same time and place (physical or virtual), using the same course materials. The only difference is that Math students enroll in Statistics 101, and Psychology students enroll in Psychology 101. A problem arises in this situation when the Enterprise system treats these sections as separate groups. In the Learning Management System, they need to be treated as a single group, or at least the LMS needs to know they are related.

One approach is to resolve this in the source system before passing Groups and Memberships over to the target system. In other words, a single group (perhaps called "Introductory Statistics", without the Math or Psychology designator) would be created in the Learning Management System and membership from both groups in the Enterprise system would be passed to this single group in the LMS. Another approach is to pass two separate groups to the target system, but relate them to each other through the use of the Relationship element. In this case, the two groups could be tagged as follows in the Relationship element:

In general, the best practice would be to resolve the issue in the source system, before passing the group and membership data to the target system, but there may be cases where the second approach is required.

7.5 Using Membership

7.5.1 Assigning Group Membership Role-type

Roletype is a data structure in the Group Membership object that has a defined set of domain values. This means that only those values defined in the domain can be used for this element. Recognizing that no defined list of roles can ever be absolutely complete; the optional element <subrole> can be used to further qualify a person's role in a group. It is essential to have a defined list of values for the mandatory <roletype> element so source systems can generate standard Group Membership data objects that target systems can process without having to first negotiate the meaning of role-types with the source system. To help developers understand what meaning is embedded in each of the role-type values, the Table 7.1 shows the LMS functions to which each roletype will typically have access. This is not intended to be a precise and exclusive list of all functions that these roles will have access to in all LMSs. Rather, it is provided as an interpretive guide intended to communicate the meaning the developers of the specification had in mind for each role. In addition, access to these functions will be less for some sub-roles. For example, a supervisor may be a sub-role for a manager, and a supervisor will likely not have access to results for the people they supervise.

Table 7.1 The LMS functions typically available to each roletype.



01
Learner

02
Instructor

03
Content Developer

04
Member

05
Manager

06
Mentor

07
Administrator

08
Teaching Assistant



R

M

R

M

R

M

R

M

R

M

R

M

R

M

R

M

Learning Content
X



X



X

X

X



X



X



X

X

X

X

Learner Enrollment
X

T

X

X





X

T









X

X

X



Group Roles
X



X







X



X



X



X

X

X



Learner Submission
T

T

X











S



S



X







Unofficial Results
T



X

X









S



S



X

X

X

X

Official Results
T



X

X









S



S



X

X

R



Final Results
T



X

X









S



S



X

X

R



Certification
T



X

X









S



S



X

X

X



Note: The key is: X=Available, R=Read, M=Main, S=Some, T=Theirs.

In any particular implementation or in any specific vendor's product, the Instructor role and the Administrator role will frequently have several sub-roles.

7.6 IMS Harmonization

The IMS Enterprise Specification is complemented by the IMS Learner Information Package (LIP) Specification [LIP, 01a], [LIP, 01b],[LIP, 01c]. There is some confusion about when and where the two specifications should be used and so the following recommendations are made:

There may be some confusion between the IMS Enterprise, IMS LIP and the IMS Question and Test Interoperability (QTI) Results Reporting Specifications with respect to exchanging assessment results. The following recommendations are made:

7.7 Example Set

The set of examples available to demonstrate the usage of the IMS Enterprise Specification V1.1 are listed in Table 7.2.

Table 7.2 List of examples demonstrating the V1.1 IMS Enterprise Specification.

Directory/File Name

Description

Examples/person/
singleperson01.xml
The creation of a single Person record that demonstrates all of the data objects available.
Examples/person/
multipleperson01.xml
The creation of three Person records - one as a new record, one as an update transaction and the third as a delete transaction.
Examples/group/
singlegroup01.xml
The creation of a single Group record that demonstrates all of the data objects available.
Examples/group/
multiplegroup01.xml
The creation of two new Groups.
Examples/group/
multiplegroup02.xml
The creation of a new Group and a child Sub-group. The relationship is defined bi-directionally i.e. from the perspective of the child and the parent.
Examples/group/
multiplegroup03.xml
A demonstration of the usage of the Group cross-listing feature within the <relationship> element.
Examples/membership/
singlemembership01.xml
The creation of a single Membership record that contains multiple Members each with a defined role.
Examples/membership/
multiplemembership.xml
The creation of multiple Membership instances each of which references a single Member.
Examples/mixed/
mixed01.xml
A demonstration of how a V1.0 IMS Enterprise XML instance, using proprietary extensions, is converted to use the equivalent structures in V1.1. This example demonstrates the usage of all of the IMS Enterprise core data objects.
Examples/mixed/
mixed02.xml
This example demonstrates the usage of all of the IMS Enterprise core data objects together.

8. Proprietary Extensions

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

Table 8.1 List of proprietary extension elements.

Extension Element Name
Host Element
Description
extension
properties
The proprietary extension facility for the <properties> structure.
extension
person
The proprietary extension facility for the <person> structure.
extension
group
The proprietary extension facility for the <group> structure.
extension
role
The proprietary extension facility for the <role> structure.

Note: These elements are only used if the suppliers of the Enterprise solution require proprietary features that are not supported by the available range of elements. It is recommended that these elements are used sparingly.

9. V1.0/V1.01/V1.1 Issues and Compatibility

9.1 V1.1 Functional Additions

The elements listed in Table 9.1 are used to indicate where new functionality has been added in the V1.1 Specification:

Table 9.1 List of V1.1 specific elements.

New Element Name
Host Element
Description
sourcedid
Several elements.
Extended to allow multiple sourcedid allocations and their identification.
userid
person
Extended functionality including the password, encryption type and authentication mode.
partname
name
Support for a broader range of name parts supplied in their component form.
disability
demographics
An indication of the disability classification/coding of the Person.
systemrole
person
Used to identify the Person's role with respect to access of the computer systems.
institutionrole
person
Used to identify the different roles the Person has within the institution.
interimresult
role
Support for multiple interim results to complement the final results structure.

9.2 V1.0/V1.01/V1.1 Compatibility

The basic structure of V1.1 is backwards compatible with previous versions. All of the extension features in V1.0/1.01 have been maintained within V1.1. The outstanding issues for compatibility are:

9.3 V2.0 Specification and Compatibility

At the current time it is unclear the extent to which the V2.0 will be backwards compatible with the V1.1 Specification. The anticipated migration from V1.1 to V2.0 is:

This approach will be possible because the V2.0 Specification is based upon a collection of data objects including those necessary for the provision of a common communications infrastructure. The definition of these new data objects includes behavior as well as the data model.

10. 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:

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 Enterprise instance the conformance statement shall:

10.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 of the IMS Enterprise Information model V1.1 [Ent, 02a], is a summary of the information given in the 'Interoperability Statement'. The intention is for the 'Conformance Summary' to be informative in nature. Completion of the two columns is intended to reflect:

10.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) of the IMS Enterprise Information Model [Ent, 02a]. 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.

10.4 Completing a Conformance Summary

There is a close relationship between the 'Conformance Summary' and the 'Interoperability Statement'. The guidelines for completing these tables are:

10.5 An Example Conformance Statement

Table 10.1 shows an example 'Conformance Summary'. This statement is what would be typical of a V1.01 implementation for a V1.1 application i.e. none of the new V1.1 functions are supported.

Table 10.1 Enterprise conformance summary.

Enterprise Conformance Summary (Version 1.1)



Publish

Accept

properties
Y

Y

person
Y

Y

     recstatus
N

N

     sourcedid
Y

Y

     userid
Y

Y

     name
Y

Y

     demographics
Y

Y

     email
Y

Y

     url
N

N

     tel
Y

Y

     adr
Y

Y

     photo
Y

Y

     systemrole
N

N

     institutionrole
N

N

     datasource
N

N

group
Y

Y

     recstatus
N

N

     sourcedid
Y

Y

     grouptype
Y

Y

     description
Y

Y

     org
Y

Y

     timeframe
Y

Y

     enrollcontrol
Y

Y

     email
Y

Y

     url
Y

Y

     relationship
Y

Y

     datasource
N

N

membership
Y

Y

     sourcedid
Y

Y

     member
Y

Y

          sourcedid
Y

Y

          role
Y

Y

               recstatus
N

N

               subrole
Y

Y

               status
Y

Y

               userid
Y

Y

               date
Y

Y

               timeframe
Y

Y

               interimresult
N

N

               finalresult
Y

Y

               email
Y

Y

               datasource
N

N

     

Note: All of the core data structures are supported.

Appendix A - Glossary of Terms

adminperiod
The adminperiod element is used within the timeframe element to contain a short human readable description for the administrative or academic period for the duration of the Group. It is a character string [1-32].
adr
The address element is a part of the person element. The address contains information such as the street, region, country, zip code, etc.
authenticationtype
The authenticationtype attribute is used on the userid element to identify the authentication mechanism to be applied to control the user's access to the learning environment. It is a character string [1-32]. This attribute was added as part of the V1.1 release.
bday
The bday element is used within the demographics element to store the date of birth of the Person. This is a character string [1-20] containing the date in the ISO8601 format (YYYY-MM-DDTHH:MM:SS).
begin
The begin element is used within the timeframe element to define when a Group is to be made available for participation. It is a character string [1-20] containing the date in the ISO8601 format (YYYY-MM-DD).
comments
The comments element is used as the general element in which comments and/or statements are supplied. When used as a comment this information is parsed through the XML parser (unlike and XML comment). The lang attribute is used to indicate the language of the comment text. This is a character string [1-2048].
country
The country element is used within the adr element. It is used to store the country component of the address e.g., Brazil, China, etc. It is submitted as a string of up to 64 characters in length and the content is based upon the ISO3166 standard.
datasource
The datasource element is used in two ways: by the properties element to indicate the source system for the data transaction; it is also used in the person, group and role elements to indicate the original source of the data i.e. this could be different from the system currently attempting to exchange the data.
datetime
The datetime element is used by several elements. 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 the form of: YYYY-MM-DDTHH:MM:SS i.e. year, month, day, hour, minute and second.
demographics
The demographics element is used within the adr element. It is used to store the learner information for demographic information about the learner e.g., gender, place of birth, etc.
description
The description element is used within the group element to describe the Group. 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 demographics element to store information about the nature of the Person's disability. Each disability description is contained in a separate instance of the disability element; there is no agreed vocabulary recommended for usage with this element. This element must not be used to store information about the access preferences to the learning environment as a result of any disability. This is a character string [1-32]. This element was added as part of the V1.1 release.
email
The email element is used in the person and group elements to store the corresponding e-mail address for the Person or Group respectively. This is a character string [1-256].
end
The end element is used within the timeframe element to define when participation in a Group is to finish. It is a character string [1-20] containing the date in the ISO8601 format (YYYY-MM-DD).
enrollaccept
The enrollaccept element is used within the enrollcontrol element to indicate if enrolments to the Group are being accepted. The contents are enumerated as either '0=No' or '1=Yes' in the form of a single integer.
enrollallowed
The enrollallowed element is used within the enrollcontrol element to indicate if the target system is permitted to enrol into the Group. The contents are enumerated as either '0=No' or '1=Yes' in the form of a single integer.
enrollcontrol
The enrollcontrol element is used within the group element to contain the enrolment conditions currently permitted for the Group. These enrolment conditions are defined using the enrollaccept and enrollallowed elements.
enterprise
The enterprise element is the root element of the IMS Enterprise XML binding. All IMS Enterprise XML instances must contain one and only one occurrence of this element.
extadd
The extadd element is used within the adr element to provide extra address space. It is an optional field that can occur only once. It is used to contain any non-street components of the address e.g., suite number, company name, etc. It is a character string [1-128].
extension
The extension element is used within the properties, person, group and role elements to act as the generic extension facility. It is permitted to contain any defined element plus any other elements that are defined within the <!DOCTYPE> structure at the head of the XML instance file.
extref
The extref element is used within the photo element to contain the external reference for the image file. This reference could be a URL. It is a character string [1-1024].
family
The family element is used within the name element. It is an optional element that can occur once at most. It is used to contain the family name component (this is not necessarily the last name). It is a character string [1-256].
finalresult
The finalresult element is used within the role element to store the final results assigned to the Person or Group. Each instantiation of the finalresult element is used to contain a single score. The ability to pass multiple final results was added as part of the V1.1 amendments.
fn
The fn element is used within the name element and it must always occur once whenever the name element is used. It is used to contain the formatted name as a character string [1-256]. The format of the contained name is undefined.
full
The full element is used within the description element. This element is used to contain a paragraph of text i.e. a string of characters (1-2048).
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. The content is enumerated as '0=Unknown', '1=Female' and '2=Male'.
given
The given element is used within the name element to contain the Person's given name (this is not necessarily the first name). The name may contain a single given entry. It is a character string [1-256].
group
The group element is used within the enterprise root element to contain information about learning Groups. The root element may have any number of Group records each contained in its own group element. The Group construct is an abstract representation for any appropriate collection of learning activities/events e.g., classes, courses, etc. The Group is one of the four core data structures defined within the Enterprise Specification.
grouptype
The grouptype element is used within the group element to contain the information that allows the Group to be categorized into one or more coding schemes with any number of levels supported within each scheme.
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.
idtype
The idtype element is used within the member element to indicate if the Member is a Group or a Person. The content is enumerated as either '1=Person' or '2=Group'. It is an integer [1 or 2].
imgtype
The imgtype attribute is used with the photo element to identify the type of image. It is recommended that MIME notation is used. This is a character string [1-32].
institutionrole
The institutionrole element is used within the person element to contain the roles of the individual within the institution. Each role is described using a separate instantiation of the element. This is an empty element with the data selected from the enumerated vocabulary contained within the institutionroletype attribute. The primaryrole attribute is used to indicate if the corresponding role is the Person's primary role within the institution. This element was added as part of the V1.1 release.
institutionroletype
The institutionroletype is a mandatory attribute for the institutionrole element. It is a character string [1-32] that has the enumerated content of: Student, Faculty, Member, Learner, Instructor, Mentor, Staff, Alumni, ProspectiveStudent, Guest, Other, Administrator and Observer. This attribute was added as part of the V1.1 release.
interimresult
The interimresult element is used within the role element to store the interim results assigned to the Person or Group. Each instantiation of the interimresult element is used to contain a single score. Multiple interim results can be returned and the resulttype attribute is used to define the type of interim result e.g., Mid-term, etc. This element was added as part of the V1.1 release.
label
The label element is used within the relationship element to describe the nature of the relationship between the host Group and the Group being described. It is a short human-readable description. This is a character string [1-32].
lang
The 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.
level
The level attribute is used with the typevalue element to indicate the coding level assigned to the group. Level '1' is usually the highest level with level '2' a further refinement, etc. This is a character string [1-2].
list
The list element(s) is used within the values element to contain the specific value that the associated result may take. This element is only used if the valuetype attribute of the values element is equal to zero (0). If the list element is used then the value recorded in the associated results element must be contained within one of the instantiations of list. It is a character string [1-32].
locality
The locality element is used within the adr 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 64 characters.
long
The long element is used within the description element. This element contains a long character string (i.e. 1-256characters) that is used to characterize the associated description material. The long entry is used in conjunction with the optional short and full elements.
max
The max element is used within the values element to define the maximum numerical value that can be assigned to the interim or final result. This element is only used if the valuetype attribute of the values element is set to one (1). It is a decimal number in the range 0-9999.9999.
member
The member element is used within the membership element to contain the details about the Group's or Person's role within the host membership Group. At least one set of member details must be defined within the membership element.
membership
The membership element is within the enterprise root element to contain information about the members of a Group. The members may be a Person or another Group. Any number of Membership definitions can be contained in a single XML instance.
min
The min element is used within the values element to define the minimum numerical value that can be assigned to the interim or final result. This element is only used if the valuetype attribute of the values element is set to one (1). It is a decimal number in the range 0-9999.9999.
mode
The mode element is used, optional, within the finalresult and interimresult elements to provide a short descriptive name for the type of scoring supplied e.g., 'Letter Grade', 'Percentage', etc. It is a character string [1-32].
n
The n element is used within the name element to contain the name structure broken down into its component parts. It contains the family, given, other, prefix, suffix and partname elements. Each name can optionally have a single n element.
name
The name element is used within the person element. It is used to store the appropriate name of the learner. Each name is exchanged using its own name element. The name may be entered through its component parts i.e. using the partname element.
nickname
The nickname element is used within the name element to contain the formatted name for the way the Person prefers to be addressed. This is a character string [1-256].
org
The org element is used within the group element to identify the organization that is administering or sponsoring the Group.
orgname
The orgname element is used within the org element to store the name of the sponsoring or administering organization. It is a character string [1-256].
orgunit
The orgunit element is used within the org element to contain the name of the sponsoring or administering unit within the organization. It is a character string [1-256]. Multiple units within the organization can sponsor or administer the same Group.
other
The other element is used within the name element to contain the other name parts that have not been allocated their own structure. This is a character string [1-256]. This field is deprecated in favour of the partname element.
partname
The partname element is used within the n element to contain a component of a name. The type of component is identified using the partnametype attribute. This is a character string [1-256]. This element was added as part of the V1.1 release and it should be used to replace the other element.
partnametype
The partnametype attribute is used with the partname element to define the type of name component being stored. Examples include 'Paternal', 'Maternal', 'Initials' etc. This is a character string [1-64]. This attribute was added as part of the V1.1 release.
password
The password attribute on the userid element is used to contain the password allocated to the user identified in the associated Person data object. It is a character string [1-1024]. This is the actual password for the user and so this should be encrypted using the algorithm identified in then associated pwencryptiontype attribute. This attribute was added as part of the V1.1 release.
pcode
The pcode element is used within the adr element only. This element is used to contain the post code component of the Person's address. It is a character string [1-32]. The format of the code will vary from country to country.
person
The person element is used within the enterprise root element to contain information about an individual learner. The root element may have any number of Person records each contained in its own person element. The Person is one of the four core data structures defined within the Enterprise Specification.
photo
The photo element is used within the person element. It is used to contain the reference to an external location where the Person's photograph is stored. Each Person structure may contain one photo element.
pobox
The pobox element is used within the adr element within the person element. It is used to store the PO Box number component of the address - if available. It is a character string [1-32].
primaryrole
The primaryrole attribute is used on the institutionrole element to indicate if the associated role is the primary role within the institution. This is a mandatory attribute and it content is enumerated as 'Yes' (it is the primary role) and 'No' it is not the primary role. This attribute was added as part of the V1.1 release.
prefix
The prefix element is used within the name element to contain the name part that precedes the name itself e.g., 'Mr', 'Mrs', 'Dr', etc. The partname element should not be used to supply similar information. It is a character string [1-32].
properties
The properties element is used within the enterprise root element to contain the transaction message header information. Each Enterprise XML instance must contain one properties element that acts as the container for all of the exchange control information e.g., source and destination sourcedids.
pwencryptiontype
The pwencryptiontype attribute is used on the userid element to describe the type of encryption used on the password (as carried in the password attribute). Possible content includes 'PKC', 'MD5', etc. It is a character string [1-32]. This attribute was added as part of the V1.1 release.
recstatus
The recstatus attribute is used to define the type of transaction that is being attempted. It is an optional attribute of the person, group and role elements. The possible value for recstatus are enumerated as '1=Add', '2=Update' and '3=Delete'. The behavior of error conditions is, in general, undefined however it is assumed that if this attribute is not used then the intended behavior is to 'Update' the record if it exists otherwise to 'Add' a new record.
region
The region element is used within the adr 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 information is entered as a string of up to 64 characters.
relation
The relation attribute is used with the relationship element to define the nature of the relationship. The content is enumerated as '1=Parent', '2=Child' and '3=Also known as', 'Parent', 'Child' and 'KnownAs'. This is a character string [1-8]. This attribute was amended as part of the V1.1 revision.
relationship
The relationship element is used within the group element to define the relationship of the host group and the group defined by the relationship. The type of relationship is identified using the relation attribute. The relationship is expressed as 'A' is the 'relation' of 'B' where 'A' is the Group identified within the relationship element (the contained sourcedid element) and 'B' is the Group containing the relationship element.
restrict
The restrict attribute is used, mandatory, with the begin and end elements to define if learner participation is permitted before the begin date or after the end data. The content is enumerated as '0=No' or '1=Yes'. It is an integer [0 or 1].
result
The result element is used within the interimresult and finalresult elements to contain the actual result being exchanged (only one value can be exchanged per instantiation of the interimresult and finalresult element). The type of the result being exchanged is defined by the values element also contained within the corresponding interimresult and finalresult element. It is a character string [1-32].
resulttype
The result attribute is used, optionally, on the interimresult element to define the type of interim result being reported e.g., 'Mid-term', 'Part I', etc. There is no predefined vocabulary for this content.
role
The role element is used within the member element to contain the description of the role that the Member has as a part of its membership. The member element must contain at least one role description and a Member can have more than one role. The type of role is defined using the roletype attribute and the type of transaction is defined using the recstatus attribute.
roletype
The roletype attribute is used with the role element to contain the role type definition. The content is enumerated as '01=Learner', '02=Instructor', '03=Content developer', '04=Member', '05=Manager', '06=Mentor', '07=Administrator', '08=Teaching Assistant', 'Learner', 'Instructor', 'Content developer', 'Member', 'Manager', 'Mentor', 'Administrator', 'Teaching Assistant' This is a character string [1-32]. This attribute was amended as part of the V1.1 revision.
scheme
The scheme element is used with the grouptype element to contain the Group type coding scheme. There is no agreed vocabulary for the coding scheme and so interoperability will require the agreement of an appropriate vocabulary as part of the business process mapping. It is a character string [1-256].
short
The short element is used within the description element. This element is used to contain a short character string (i.e. less than 60 characters) that is used to characterize 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.
sort
The sort element is used within the name element to contain the name structure that is used for information sorting. The parsing schemes will be vendor specific. It is a character string [1-256]. The partname element should not be used to supply similar information.
source
The source element is used within the sourcedid element. It is used to store the name/identifier of the organization responsible for the creation of the actual instance of the enterprise 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 object should be allocated a sourcedid that should be globally unique - how this is achieved is beyond the scope of this specification. The sourcedid consists of a source element and an id element. The source defines the organization responsible for the allocation and/or creation of the identifier and the id the unique value with respect to that source. The type of sourcedid can be defined using the sourcedidtype attribute.
sourcedidtype
The sourcedidtype attribute is used with the sourcedid element. The content is enumerated as 'New', 'Old' and 'Duplicate'. The 'Duplicate' entry is used to identify the redundant object. This attribute was added as part of the V1.1 release.
status
The status element is used, mandatory, within the role element to indicate if the Member is active or inactive within the Group. The content is enumerated as '0=Inactive' or '1=Active'. This is an integer [0 or 1].
street
The street element is used within the adr 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.
subrole
The subrole element is used within the role element to provide further qualification on the member's role within the Group. There is no agreed vocabulary to describe the various possible subroles. It is a character string [1-32].
suffix
The suffix element is used within the name element to contain the name part that follow the name itself e.g., 'Jr', 'Snr', 'III', etc. The partname element should not be used to supply similar information. It is a character string [1-32].
systemrole
The systemrole element is used within the person element to contain the role of the individual with the computer system environment. This is an empty element with the data selected from the enumerated vocabulary contained within the systemroletype attribute. This element was added as part of the V1.1 release.
systemroletype
The systemroletype attribute is used, mandatory, with the systemrole element to define the actual role undertaken within the learning system. The content is enumerated as 'SysAdmin', 'SysSupport', 'Creator', 'AccountAdmin', 'User', 'Administrator' or 'None'. This is a character string [1-32]. This attribute was added as part of the V1.1 release.
target
The target element is used within the properties element to contain the identifier(s) of the Enterprise system that are to receive the information contained in the associated XML instance. Each destination Enterprise system is identified using a separate target element. It is a character string [1-256].
tel
The telephone element is used within the person element. This element is used to store the appropriate telephone number (including mobile telephone, pager and facsimile numbers). The telephone number can include the county code and extension number as well as the normal area code and actual number.
teltype
The teltype attribute is used with the tel element to define the type of telephone number being stored. The content is enumerated as '1=Voice', '2=Fax', '3=Mobile', '4=Pager', 'Voice', 'Fax', Mobile' and 'Pager'. All but the '1=Voice' and '2=Fax' entries were added as part of the V1.1 amendments. It is a character string [1-8].
timeframe
The timeframe element is used within the group and role elements to define the period during which the Group or the Membership is active. The period is defined using the begin and end elements plus the adminperiod element that is used to supply a short human-readable description of the period.
type
The type element is used within the properties element to act as a control field indicator for the associated transaction. There is no agreed vocabulary for the contents of the type element and so system using this element must agree their vocabulary as part of the business mapping process. It is a character string [1-32].
typevalue
The typevalue element is used within the grouptype element to contain the classification assigned to the associated Group. Each Group must have at least one typevalue classification if its group type has been defined. It is a character string [1-256].
url
The url element is used to contain the URL for the Person or Group. This is a character string [1-1024] that contains the absolute form of the URL. The availability of this element within the person element was added as part of the V1.1 revisions.
userid
The userid element is used within the person and role elements to contain the user's identification information. It uses the password, pwencryptiontype and authenticationtype attributes to contain information that supports the storage of the user's identification information. It is a character string [1-256].
useridtype
The useridtype attribute is used on the userid element to identify the type of user identification. Some examples of this are 'NationalId' or 'InstitutionId'. There is no defined vocabulary for the range of possible identification entries. It is a character string [1-32]. This attribute was added as part of the V1.1 release.
values
The values element is used within the finalresult and interimresult elements to contain the description of the values that the result element may contain e.g., a grade from a list of possible grades or a numeric value between some minimum and maximum.
valuetype
The valuetype attribute is used, mandatory, on the values element to indicate the type of values being described. The content is enumerated as '0=List' and '1=Range'. The range is defined by a numeric minimum and maximum and the list is defined through a list of the possible grades. This is an integer [0 or 1].

Appendix B - Summary of Changes

The detailed list of changes are summarized below:

Reference in V1.01 Document
Reference in this Document
Description
Front Page
Front Page
New title for the document.
Introduction
Introduction
A complete rewrite of the introduction.


Specification Use-cases
A new Section focused on describing the core use-cases that the Enterprise V1.1 Specification is designed to support.
Other Specification Initiatives
Relationship to Other Specifications
A reworking of the relationship of this IMS Enterprise Specification to other similar specification activities.
Overall Data Model
Overall Data Model
A reworking of the description of the overall data model.


Examples of XML Instances
A series of basic and advanced XML instances demonstrating the usage of the Enterprise Specification.
Enterprise Element to LDAP Attribute Mapping
Other Specifications
The mapping of the IMS Enterprise Specification to vCard, eduPerson and LDAP.
Implementation Guidance
Implementation Guidance
Recommendations on the usage of the data structures within the specification.


Compatibility
Compatibility issues between versions 1.0, 1.01 and 1.0.
Conformance
Conformance
A new Section that describes the Conformance Summary and Interoperability statements that should be used to describe an IMS Enterprise V1.1 implementation.


Appendix A
The inclusion of a new Appendix that provides a glossary of the elements and attributes used in the specification.


Appendix B
The provision of a detailed list of changes made between the V1.01 and the V1.1 document releases.


About This Document
New details describing the document.


Revision History
Addition of the details of the release of the final version of the document.


Index
Provision of an Index to the document.

About This Document

Title:
IMS Enterprise Best Practice and Implementation Guide
Authors:
Colin Smythe, Geoff Collier, Chris Etesse, and Wayne Veres
Version:
1.1
Version Date:
01 July 2002
Status:
Final Specification
Summary:
This document presents the IMS Enterprise Best Practice and Implementation Guide. This specification describes the recommended best practices when adopting the IMS Enterprise Specification.
Revision Information:
10 June 2002
Purpose:
This is the third formal release of the IMS Enterprise Best Practice and Implementation Specification.
Document Location:
http://www.imsglobal.org/enterprise/entv1p1/imsent_bestv1p1.html

List of Contributors

The following individuals contributed to the development of this document:

Fred Beshears
UC Berkeley, USA
Kerry Blinco
IMS Australia
Glen Clingroth
Eduprise Inc.
Geoff Collier
Eduworks, Inc.
John Eyre
JISC/CETIS, UK
Chris Etesse
Blackboard Inc.
Ron Kleinman
SUN Microsystems Inc.
Kirty Levy
DigitalThink Inc.
Tim Magnor
SIIA, USA
Colin Smythe
Dunelm Services Ltd.
Wayne Veres
California State University, USA
Kimberley Voltero
WebCT Inc.

Revision History

Version No.
Release Date
Comments
Final Version 1.0
21 November 1999
The first formal release of the IMS Enterprise Best Practice and Implementation Guide;
Final Version 1.01
21 December 1999
The second formal release of the IMS Enterprise Best Practice and Implementation Guide The amendments consist of a series of bug fixes;
Final Version 1.1
01 July 2002
The amendments made in this final release of the IMS Enterprise Best Practice and Implementation Guide are:
- The document has been totally restructured when compared to the V1.01 release;
- A series of basic and advanced examples have been added;
- The Conformance Statement has been modified;
- Details on the Extensions have been added;
- A Section on Compatibility issues has been added;
- A full glossary of elements and attributes has been added as Appendix A;
- Appendix B has been added to provide the details of all the changes made in this document.

Index

A
Architecture 1
Attributes
     authenticationtype 1, 2, 3
     imgtype 1, 2, 3
     institutionroletype 1, 2, 3, 4, 5
     lang 1, 2
     level 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     partnametype 1, 2, 3, 4, 5
     password 1, 2, 3, 4, 5, 6
     primaryrole 1, 2, 3, 4, 5, 6
     pwencryptiontype 1, 2, 3
     recstatus 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
     relation 1, 2, 3, 4, 5, 6, 7, 8
     restrict 1, 2, 3, 4, 5, 6, 7, 8, 9
     resulttype 1, 2
     roletype 1, 2, 3, 4, 5, 6
     sourcedidtype 1
     systemroletype 1, 2, 3, 4
     teltype 1, 2, 3, 4, 5, 6, 7, 8, 9
     useridtype 1, 2, 3
     valuetype 1, 2, 3, 4, 5, 6, 7

C
Conformance 1, 2, 3, 4, 5
Core data objects
     Group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
     Membership 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     Person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23

E
Elements
     adminperiod 1, 2, 3, 4, 5, 6, 7, 8
     adr 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
     bday 1, 2, 3, 4, 5, 6, 7, 8
     begin 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     comments 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     country 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     datasource 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
     datetime 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     demographics 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
     description 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19
     disability 1, 2, 3, 4, 5, 6
     email 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     end 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     enrollaccept 1, 2, 3, 4, 5, 6
     enrollallowed 1, 2, 3, 4, 5
     enrollcontrol 1, 2, 3, 4, 5, 6, 7, 8
     enterprise 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
     extadd 1, 2, 3, 4, 5, 6
     extension 1, 2, 3, 4, 5, 6, 7, 8, 9
     extref 1, 2, 3, 4
     family 1, 2, 3, 4, 5, 6, 7, 8, 9
     finalresult 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     fn 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     full 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     gender 1, 2, 3, 4, 5, 6
     given 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     group 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
     grouptype 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     id 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
     idtype 1, 2, 3, 4, 5, 6, 7
     institutionrole 1, 2, 3, 4, 5, 6, 7, 8, 9
     interimresult 1, 2, 3, 4, 5, 6, 7
     label 1, 2, 3, 4, 5, 6, 7, 8
     list 1, 2, 3, 4, 5, 6
     locality 1, 2, 3, 4, 5, 6, 7, 8, 9
     long 1, 2, 3, 4, 5, 6, 7
     max 1, 2, 3, 4
     member 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     membership 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
     min 1, 2, 3, 4
     mode 1, 2, 3, 4, 5, 6
     n 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     name 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
     nickname 1, 2, 3, 4, 5, 6, 7, 8, 9
     org 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     orgname 1, 2, 3, 4, 5, 6, 7, 8, 9
     orgunit 1, 2, 3, 4, 5, 6, 7, 8, 9
     other 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
     partname 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     pcode 1, 2, 3, 4, 5, 6, 7
     person 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
     photo 1, 2, 3, 4, 5, 6, 7, 8
     prefix 1, 2, 3, 4, 5, 6, 7, 8
     properties 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
     region 1, 2, 3, 4, 5, 6, 7, 8
     relationship 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
     result 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     role 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
     scheme 1, 2, 3, 4, 5, 6, 7, 8, 9
     short 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     sort 1, 2, 3, 4, 5, 6, 7, 8
     source 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
     sourcedid 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
     status 1, 2, 3, 4, 5, 6, 7, 8, 9
     street 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     subrole 1, 2, 3, 4
     suffix 1, 2, 3, 4, 5, 6
     systemrole 1, 2, 3, 4, 5, 6, 7
     target 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
     tel 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     timeframe 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     type 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
     typevalue 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     url 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     userid 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
     values 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

G
Group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24

M
Membership 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

P
Person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23

U
Use-cases 1

V
Version 1.1 Additions
     Attributes

authenticationtype 1, 2, 3

institutionroletype 1, 2, 3, 4, 5

partnametype 1, 2, 3, 4, 5

primaryrole 1, 2, 3, 4, 5, 6

pwencryptiontype 1, 2, 3

resulttype 1, 2

sourcedidtype 1

systemroletype 1, 2, 3, 4

useridtype 1, 2, 3      Elements

disability 1, 2, 3, 4, 5, 6

institutionrole 1, 2, 3, 4, 5, 6, 7, 8, 9

interimresult 1, 2, 3, 4, 5, 6, 7

partname 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

systemrole 1, 2, 3, 4, 5, 6, 7

X
XML 1
     DTD 1, 2, 3
     XSD 1

1
For consistency with the other IMS specifications the V1.1 Enterprise DTD uses a lower-case naming convention for elements and attributes. The V1.0 and V1.01 DTDs used an upper-case naming convention.

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Enterprise Best Practice and Implementation 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 Enterprise Best Practice and Implementation Guide Date: 01 July 2002