Version 1.1 Final Specification
|
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 © IMS Global Learning Consortium 2006. All Rights Reserved. If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm. This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group. Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/enterprise/entv1p1/entv1p1speclicense.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. |
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:
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.
The structure of this document is:
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:
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).
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
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.
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.
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.
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.
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.
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.
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.
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:
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.
A schematic representation of the core data objects exchanged using the IMS Enterprise Specification is given in Figure 3.1.
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.
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).
Figures 3.3, 3.4, 3.5 and 3.6 show schematic representations of the XML binding of the Enterprise Information Model.
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.
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>
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>
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>
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>
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.
<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>
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>
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>
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>
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>
The mapping between the IMS Enterprise <person> element and the IMS LIP <identification> element is shown in Table 6.1.
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: